On Fri, Dec 9, 2016 at 8:32 AM, Jim Jagielski <j...@jagunet.com> wrote:
> It may be weird talking about httpd 2.6/3.0 when we are stuck > in a holding pattern for 2.4.24, but actually it's not a bad > idea. > > Right now, there are quite a few improvements in trunk that > should *really* be in a releasable version... Now we have some > options on how to proceed, but my modus operandi has been to > "push" as much trunk goodness back to 2.4 as possible, leaving > trunk still a nice sandbox for development on how we really want > to architecture the next gen (slave connections, etc...). So > as much as I think we should continue that, I also think it's > a disservice to keep the async, et.al. improvements in trunk, > well, in trunk. So we could fork 2.6 from trunk and work on > releasing 2.6. Assuming that we do so in a timely fashion, that > would mean we would have 3 versions out: 2.2, 2.4, and 2.6. > Considering that 2.4 is finally showing some traction, I wonder > if that's the right move. > Well, that isn't how we work, we don't fork 2.6 before 2.5.whatnot. We release 2.5.0-alpha (or -beta). Unless you want to redesign the process and open that hard-won consensus all over again. Then another -alpha/-beta, and so on, until we have consensus to tag trunk as the 2.6.0/3.0.0 release. Then we take a deep breath and fork 2.6.x/3.0.x branch from trunk. This keeps 2.5 as close to the bleeding edge as possible during the next release process, with major API changes and broken binary compatibility between the individual alpha/beta samples, so that others in our ecosystem may adapt their modules throughout the process, and are (one hopes) ready for the 2.6.0/3.0.0 release. You and I (and others, I suspect) agree there is a lot of trunk goodness to release soon. Other things that would likely happen during the 2.5.x phases are a reworking/restructuring of utility vs server facilities (something which is a complete mess at this moment), collapsing _ex() functions into their historic function names, etc. Restoring the ability to load modules out of order after the chaos of poorly thought out new 'hub-and-spoke' modules. And there are other discussions afoot around the PMC about major API changes that will break some developer assumptions, and I believe will cause us to take this to 3.0.0, not some minor revision bump. > Instead, maybe we could backport all that stuff to 2.4, in a backwards > compatible fashion. That is, basically backport trunk to 2.4. This > would give us more runway to work on httpd-nextgen. > That is very unrealistic, given that the trunk patches have broken ABI more than once a month for four years. Adapting such patches would lead to many more inane forks like the HttpProtocol Strict backport effort. The other 'instead' is that we could throw away trunk, and branch a new trunk from 2.4.x branch, if we are not comfortable releasing the contents of trunk as an alpha or beta release. I hope that's not the case.
