I'm not sure where in the conversation to add this, but I do want to point out a mechanical concern.
If we end up with API and feature freeze on branch 2.4, then we'd expect to roll 2.6. Soon enough, we'll hit a situation where 2.6 (as a release branch) can't get a feature or the next great thing because of a required API incompatible change. We would then kick out 2.8, 2.10 and so on and so forth. This seems like it would satisfy both the keep-the-stuff-stable as well as the give-users-new-stuff "sides". Mechanically, this can become tiresome for a volunteer as we work through the STATUS ceremony for each of the branches. I remember that being less than enjoyable when 2.0, 2.2 and 2.4 were all release branches. I'm fearful of a future where we may have five branches and a bugfix applicable to all (or worse... a security fix that would dictate all should be released/disclosed at the same time). -- Daniel Ruggeri On 4/19/2018 7:17 PM, William A Rowe Jr wrote: > I don't disagree with RC's entirely, or the mechanism you suggest, but > that isn't what I read as proposed. > > Our issue is that every httpd must be distinguished, we won't ship > four tarballs all claiming 2.4.34 (GA). Which one is the person > complaining about? Are we back to SHA signature of the source tarball > (that isn't even assuredly what they built the binary from?) > > We can decorate the rc in the versioning, but that isn't part of 2.4.x > API, unless we swap out the "-dev" string tag for an "-rc#" value. > > It is not reasonable to lock a branch for an indeterminate length of > time. Branching the RC into what becomes the final release, and making > it painful to backport first to 2.4.x and finally 2.4.n-rc branch > might help discourage disruptive backports, but there is no suggestion > yet of what is acceptable, either on such a frozen main branch or rc > branch. > > In fact our policy reflects that two competing release candidates is > an entire valid and even expected situation, and any process that > further blocks this should be firmly rebuffed. > > As it reads so far the proposal is the way we do things, now > conserving subversion numbers as precious, if only to reenforce a > stake in the ground that version major and minor numbers are similarly > precious, (which they are not.) > > With the addition of freezing changes on 2.4.x branch for a time we > succeed in impeading progress towards version .next, while not > otherwise changing the status quo. > > What you suggest is yet another thing, based on forking the RC release > branch, and I haven't seen that accepted by the committee yet. > > On Thu, Apr 19, 2018, 16:43 David Zuelke <[email protected] > <mailto:[email protected]>> wrote: > > 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 > <[email protected] <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> wrote: > >> The idea is encouraging and fostering a broader test audience. > >> > >> > >> On Apr 19, 2018, at 11:44 AM, William A Rowe Jr > <[email protected] <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> wrote: > >>> > >>> > >>> > >>> > On Apr 19, 2018, at 11:26 AM, William A Rowe Jr > <[email protected] <mailto:[email protected]>> > >>> > wrote: > >>> > > >>> > On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski > <[email protected] <mailto:[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 > >> > >> > >> 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. > >> > >> >
