Am 19.04.2018 um 17:37 schrieb Jim Jagielski:
On Apr 19, 2018, at 11:26 AM, William A Rowe Jr <wrowe@xxxxxxxxxxxxx> wrote: On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski <jim@xxxxxxxxxxx> wrote:With all this in mind, should we try to set things up so that the next release cycle uses the concept of RCs? If so, and if people like, I can come up with a baseline proposal on the process for us to debate and come to some consensus on.Would you define an RC? What changes are allowable in that branch?The idea is that right now we take an existing state in SVN and tag it as, for example, 2.4.121. We then vote on that tag and the artifacts released from that tag. No work is done on the 2.4 branch while testing is done so that we ensure that the SVN rev on branch == the one for the tag. Instead, we tag at 2.4.121-RC1. We do the exact same. If the vote does not pass, we continue on the 2.4 branch, fix the issues, and then tag a 2.4.121-RC2. Rinse and repeat. If the vote does pass we tag the branch, which is still == RC# at this stage, as 2.4.121 (ap_release.h mods included). We still even at this stage test and vote on the release as we have for decades. If it passes, we release. If not, for some reason, we have burned the 2.4.121 release, bump to 2.4.122 and GOTO the above. This is the overall idea... more flesh to be added.
IMHO we should aim at keeping the RC phase as stable as possible and focuse on the code from which we tagged RC1 and which we actually want to release. So after RC1 there should be only fixes for regressions, no other fixes or backports.
Other projects for example branch at the start of the release process (using your version example 2.4.121 here):
- branch 2.4.x as a 2.4.121 branch - tag 2.4.121-RC1 on that branch - allow for a week or two (?) of public testing - fix incoming regressions - patches go via trunk to 2.4.x to 2.4.121 branch - cut new RCs if previous RC needed fixes- create final release tag from last RC plus some script driven version adjustments
- do final release voteWhile we are doing RCs backport and other fixing work could proceed on the 2.4.x branch, because the RCs are created from the version branch.
... 2c ... Rainer
|( ! ) Warning: include(msgfooter.php): failed to open stream: No such file or directory in /var/www/git/apache2-developers/msg03814.html on line 139|
|( ! ) Warning: include(): Failed opening 'msgfooter.php' for inclusion (include_path='.:/var/www/git') in /var/www/git/apache2-developers/msg03814.html on line 139|