On April 23, 2018 11:30:07 AM CDT, William A Rowe Jr <wr...@rowe-clan.net> wrote: >On Sun, Apr 22, 2018 at 11:34 AM, Daniel Ruggeri <drugg...@primary.net> >wrote: >> >> 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. > >Thought exercise... if it is decided that version 3.5.x added an all >around >nice set of features, and we had platform maintainers as committers who >wanted to keep backporting to that tree at this project, well... they >could >elect to maintain that version as a long lived branch and collaborate >on >it while we went on our merry way through 3.15.0, even 4.1.x as a >group. > >In other words, wherever we have three committers who will cultivate a >long lived release, they can do that. This doesn't differ from how a >few >individuals kept 2.0, and later, 2.2 alive for a significant period of >time >after the next major release. When interest cooled, each was retired.
Of course - this being Open Source and we being volunteers, we work on what we want to work on :-). I generally see that doesn't happen much for projects operating this way, though. My perception is that typically once 2.7.0 is released, work dies off quickly for 2.6.x. As mentioned elsethread, what the distros are signing up for (right or wrong) is to put a stake in the ground on a certain version and to select specific patches for fixes alone. If we were to do the same, it may be a duplication of effort. Now... That doesn't preclude us from operating like Ubuntu does, for example, with their LTS style releases where we do "2.6.x will get fixes only for X years, but 2.7+ will get features until the next LTS cut". I think that idea may be what you have in mind. So, in that world we have three long lived branches: trunk, release and LTS. I can see us operating in that way... and to make backports less cumbersome, we could further declare that a fix accepted in STATUS for the LTS branch is accepted also into the release branch. One more thing to point out that I didn't explicitly say in the previous message is that this suggestion implies the release branch regularly gets cut from trunk (rather than growing and diverging on its own). This helps avoid "locking" features in trunk indefinitely because of the time between Maj.Min bumps. -- Daniel Ruggeri
