Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])
Yup, that's exactly it. Have a release branch, iterate there, and in
the meantime, work in the version series branch can continue. That
brings one huge benefit over the current model already: no freezes
necessary, no potential additional breaks after a "burned" version.
On Thu, Apr 19, 2018 at 9:19 PM, Rainer Jung <rainer.jung@xxxxxxxxxxx> wrote:
> Am 19.04.2018 um 17:37 schrieb Jim Jagielski:
>>> On Apr 19, 2018, at 11:26 AM, William A Rowe Jr <wrowe@xxxxxxxxxxxxx>
>>> 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
> 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
> - do final release vote
> While 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 ...