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 <[email protected]> wrote: > Am 19.04.2018 um 17:37 schrieb Jim Jagielski: >> >> >> >>> On Apr 19, 2018, at 11:26 AM, William A Rowe Jr <[email protected]> >>> wrote: >>> >>> On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski <[email protected]> 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 > > 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 ... > > Rainer
