Yeah - I think my main concern is really just around the backporting process with STATUS and how that will have issues scaling across many branches. Further, as each branch deviates, it becomes more of a cognitive exercise for developers to figure out if the fix in branch XYZ is applicable and the same in ABC.
The more I think about it, the more I *really* like a semver-ish approach where major represents the ABI that will not be broken, minor represents the feature set (for backwards compatibility) and patch represents forward-compatible changes/fixes. This may be, in spirit, what you are suggesting. I'd further add that no directives are added in patch releases, but minor releases would be fair game. How we choose to maintain that behind the scenes is a thought exercise. Given that most of our users get httpd from distros, I'd be in favor of having only two long-lived branches: trunk and release. The distros are already taking the point-release they want and curating fixes/changes for it, so they will be doing what they do regardless of our direction. For administrators building httpd themselves, they have control of when to pull the trigger on a build and what they build, so I don't think they would be harmed by such a change. Hopefully this isn't considered a caustic statement (it is not intended to be), but I feel that this would bring our versioning practices more in line with what most OSS projects are doing these days and also avoid some of the issues managing several branches. (I really am digging this idea :-) I'm glad folks have proposed it...) -- Daniel Ruggeri On 4/20/2018 12:08 AM, William A Rowe Jr wrote: > Let me counter with this... Rather than break the API every m.n > release, what if we roll on to 2.6 with no ABI breakage, or resolve > with impumity everything wrong in 3.0 with a firm commitment not to > break it again till 4.0? > > This might be the root problem of our trying to !is versioning semantics. > > > On Thu, Apr 19, 2018, 19:39 Daniel Ruggeri <drugg...@primary.net > <mailto:drugg...@primary.net>> wrote: > > 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 <dzue...@salesforce.com > <mailto:dzue...@salesforce.com> > > <mailto:dzue...@salesforce.com <mailto:dzue...@salesforce.com>>> > 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 > > <wr...@rowe-clan.net <mailto:wr...@rowe-clan.net> > <mailto:wr...@rowe-clan.net <mailto: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 <mailto:j...@jagunet.com> > > <mailto:j...@jagunet.com <mailto: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 <mailto:wr...@rowe-clan.net> > <mailto:wr...@rowe-clan.net <mailto: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 <mailto:j...@jagunet.com> > > <mailto:j...@jagunet.com <mailto:j...@jagunet.com>>> wrote: > > >>> > > >>> > > >>> > > >>> > On Apr 19, 2018, at 11:26 AM, William A Rowe Jr > > <wr...@rowe-clan.net <mailto:wr...@rowe-clan.net> > <mailto:wr...@rowe-clan.net <mailto:wr...@rowe-clan.net>>> > > >>> > wrote: > > >>> > > > >>> > On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski > > <j...@jagunet.com <mailto:j...@jagunet.com> > <mailto:j...@jagunet.com <mailto: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. > > >> > > >> > > >
