[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 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.