> Am 20.01.2017 um 01:46 schrieb Eric Covener <cove...@gmail.com>: > > On Thu, Jan 19, 2017 at 4:43 PM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: >> I think one of our disconnects with 2.4 -> 2.6 is that in any other >> framework, there would be no ABI breakage in 2.6. That breakage >> would be deferred to and shipped as 3.0. >> >> The httpd project choose to call 2.minor releases as breaking >> changes. Due to poor design choices, or frequent refactorings, >> this essentially shifted our release numbering schema down one >> digit. So 2.6.0 is not an enhancement release, but a major release >> in the general understanding of these things. This might be the root >> of Jim's and my failure to come to any consensus. >> >> Right now, there are a number of gratuitous breaking changes on trunk >> that change binary ABI. I'm considering a trunk fork to preserve these >> changes (branches/3.x-future/?) and reverting every change to trunk/ >> which was otherwise a no-op. Namespace, decoration, anything that >> prevents a user from loading a 2.4.x module in 2.next. And then we >> can look at what is a valid reason to take us to 3.0. > > The "why" missing here is presumably to allow a 2.6 to be cut from > trunk. But in that case, why not just fork it from 2.4 w/o a major nor > magic cookie bump and let 2.4 become the more conservative stream?
+1 Just some brainstorming: LTS/Stable/Feature branches 2.2.x/2.4.x/2.6.x for now 2.2.x/2.6.x/2.8.x if we think new features in 2.6 are stable and want to add more features 2.4.x/2.4.x/2.6.x if we end LTS for 2.2, the new LTS can be a stable branch 2.2.x/2.4.x/2.8.x in extreme cases, we could ditch a feature branch and move on. - we continue working in trunk - backports to LTS/stable branches as now, review then commit - backports to feature branches: commit, then review - LTS is the support promise, stable/feature can move more freely - Feature is completely "experimental", we make no promises - Distros can support stable longer than we do, which is basically the model they are doing now for their LTS. - people will argue for more than 1 LTS release, but I think that is too much for the project, more something for a commercial undertaking (and there could be odd version numbers in there as well, but does not matter to me) > [...] Stefan Eissing <green/>bytes GmbH Hafenstrasse 16 48155 Münster www.greenbytes.de
