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. There might be some minor breakage that requires a recompilation, such as a user module allocating a req_rec. That is solved by setting a showstopper to the 2.next release to introduce _create() accessors to every structure belonging to the httpd API. There would be side determinations... would we institute such a change with the release of 2.5, or 2.6, or 3.0? Once this is complete, binary breaking ABI changes would live in their own feature development forks. They would never be folded into trunk until there was a group consensus to push forward to version next.0.0 in the immediate future. trunk/ would cease to be a sandbox of ideas unready for release. It's likely a couple-week process that I can't start till the end of next week. 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. It might be that we won't end up shipping 2.6 because other good and necessary binary-breaking-changes occur between now and in the near future, or that these exist on trunk. But if we defer the gruntwork of renaming things and whitespace mop-up etc until a short several-week period prior to the actual major.0.0 release, then we can keep trunk/ in a much more releasable state for all the new features. We may have the impetus for a 3.0 release in the near future, we may not, but I'm sure the idea that 2.5 is a 'major' ABI-breaking release is not serving us well.
