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? New major/minor downstream releases can jump to 2.6 without much fuss, and current ones can try to track closer to current 2.4.x as they age. We can find some new religion about how trunk work if some concise policy doc appears that we can all agree on. > But I think the frustration about not being able to ship new > features has a lot to do with our history of breaking API's every time > we ticked up the version minor number. Is there a (remarkable) inability to ship new features today? Somehow simultaneously with too many new features shipping in 2.4.x? I'm not following this part.
