Add manpages for OpenSSL version 3.2 about web HOT 8 CLOSED

Actually, that's not a bad idea.

from web.

A slight problem here is that we haven't actually branched yet (so 3.2 is still running off the master branch). Which of course means that the 3.2 man pages and the master pages will be identical. Not sure if our scripts will be able to handle it if we added 3.2 to the man pages but there is no branch for it...

from web.

You are right, my reminder was premature. Nevertheless, I'll leave it open as a reminder for the moment when the branch gets created. :-)

from web.

A slight problem here is that we haven't actually branched yet (so 3.2 is still running off the master branch).

Side note: in my company we solved the problem of "early branching"(*) for QA release candidates by creating release branches on the master branch and fast-forwarding them on master until we decide that the release candidate will be released.

(*) In our case, the branch name affects the name of the build artifacts.

from web.

It is a good idea... but you need to know what you do, i.e. not do the natural mistake of releasing from that "early branch". I believe it's the possibility of such a mistake that had led us to dismiss the idea of an "early branch" in previous conversations...

from web.

Releasing from the 'early' branch is no problem at all. It is not a requirement that the release branch and the master branch must depart immediately at the moment the first version is released. The only essential thing is that the (stricter) policies of the release branch must be obeyed when fast-forwarding.

In other words, the master branch is treated temporarily as a 'staging branch' for the openssl-3.2 branch and only pull requests which are admissible for the release are allowed to be merged to master. The release branch openssl-3.2 follows (i.e, is an ancestor of) the master branch, but fast-forwards of openssl-3.2 to the tip of master branch are made only manually and only as long as all incoming commits on master fulfil the requirements of the release policy. The first commit on master which is not admissible would terminate the fast-forward and would require a true branching.

from web.

This pattern would be useful for the alpha-phase and the early beta-phase, as long as the overwhelming majority of pull requests is still intended for the release and all others can be withheld for a while. It's the burdon of holding back PRs against the extra burdon of cherry-picking to two branches, which you need to weigh against each other.

from web.

The permission to push such types of fast-forwards of 'early' release branches to the central repository without pull request is restricted in my company (by pre-receive-hook) and granted only to a small number of people who coordinate the releases.

from web.