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)])
On 04/19/2018 09:19 PM, Rainer Jung 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> 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 vote
+1. Sounds reasonable, gives more time for testing avoids freezes on the 2.4.x branch while keeping the RC stable. Let's
try this and see the results.