The main difference is that you have a release branch in which fixes to bugs or regressions found during 2.4.x RCs can be made, while work on 2.4.(x+1) can continue in the main 2.4 branch.
Another benefit is that people who do automated builds (e.g. me) can grep for "RC" in the version number and have it fetch from https://dist.apache.org/repos/dist/dev/httpd/ instead. The changelogs are more readable as well, because it's obvious which intermediary RC releases belong together. If you look at https://archive.apache.org/dist/httpd/CHANGES_2.4, there is zero indication that e.g. 2.4.31 was never released. On Thu, Apr 19, 2018 at 10:53 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > What possible improvement occurs if there is no branch discipline > on 2.4.x development? We just echoed effectively your proposal, > using numbers rather than RC designations, and still .33 has this > host of issues. With no release since .29, the branch was in this > continuous state of flux between 2.4.30 and 2.4.33. Testing the > 2.4.30 release did not result in a better, eventual 2.4.31, testing > .31 didn't result in a better .32, and even the final .33 had its own > issues. > > This would have been precisely the same outcome between RC1 > and RC4, if the project doesn't keep the branch stable for even the > week or months required to craft a successful release, and if that > occurs on 2.4.x branch, that is an interruption of effort towards > release n+1, frustrating contributors. > > Note we don't publish anything not approved by the PMC, so > there would be the same "vote" to release an RC. > > Net <-> net, this is the status quo which failed us so badly this > past winter (now with alphabetic characters!) > > > On Thu, Apr 19, 2018 at 10:51 AM, Jim Jagielski <j...@jagunet.com> wrote: >> The idea is encouraging and fostering a broader test audience. >> >> >> On Apr 19, 2018, at 11:44 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: >> >> Unless I misunderstand... >> >> 2.4.30-RC1 (rejected) >> 2.4.30-RC2 (our .31, rejected) >> 2.4.30-RC3 (our .32, rejected) >> 2.4.30-RC4 -> 2.4.30 GA (our 2.4.33 release) >> >> With all the associated changes in between, no actual change in branch >> management, scope, feature creep, etc? >> >> This sounds like dressing up the status quo with different labels. >> >> >> >> On Thu, Apr 19, 2018, 10:37 Jim Jagielski <j...@jagunet.com> wrote: >>> >>> >>> >>> > On Apr 19, 2018, at 11:26 AM, William A Rowe Jr <wr...@rowe-clan.net> >>> > wrote: >>> > >>> > On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski <j...@jagunet.com> 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 >> >> >> Not necessary to freeze; a tag can always be applied to an older rev. >> >>> 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. >> >>
