Re: 2.4.x and 2.6.x ... next steps
Le 11/09/2018 à 20:35, Jim Jagielski a écrit :
I'd like for us to seriously consider the next steps
related to the future of httpd.
In trunk we have some stuff that can be easily, or, at
least, *somewhat* easily backported to 2.4.x, and I
personally think that we should do that.
My only comment is that, from my personal point of view, we should start
from branches/2.4.x and not from trunk.
But we also
have some items which cannot be backported due to API/ABI
concerns, and some of these are pretty useful things.
And finally, we have some things in trunk that will likely
need to be majorly fixed or else scrapped.
The 1st thing we need to do is classify those things
within trunk. We then need to backport what we can,
and should, and then make progress on a 2.6.x release
(please note, I am using shorthand here... yes, I know
what we *really* do is a 2.5.x which then goes to 2.6.x
but I'm hopeful we all know what I mean).
This is what I propose:
o Later on this week I svn cp trunk over to branches/2.5.x
See below why.
o That branch becomes the initial source for 2.6.x
o trunk remains CTR, whereas branches/2.5.x becomes RTC
ala 2.4.x (ie: using STATUS and specific, targeted
o Backports to 2.4.x only come from 2.5.x
o We then release a 2nd alpha from branches/2.5.x
o We get 2.5.x into a releasable stage, whereas we
svn mv branches/2.5.x to branches/2.6.x
A combination of trunk's STATUS and 2.4.x's STATUS will
become the STATUS for 2.5.x... see below for the why (but
basically that file will serve as the place where those
above "classifications" will be documented).
The main goal is that this creates a somewhat "stable"
2.5.x branch which can be polished but as well serve as
the source for backports. Additional development continues
on trunk w/o mussing up 2.5.x... but there is also a path
that stuff in trunk can end-up in 2.6.x. In also allows us
to remove "experiments" in the old trunk (and now 2.5.x)
which are broken or, at least, doesn't have enough support
to warrant being released (a glance thru 2.4.x's STATUS file
for backports which are stagnated, etc provide some clues
on what those could be... at the least, this will provide
incentive to address those concerns or revert those additions)
This is why I think that backporting (and/or cleaning trunk) is easier
to manage than removing "experiments".
We know, and eventually can vote to have more reviews if we backport.
We can have "experiments" stay in 2.5.x/2.6 if no-one pays attention to it.
I have in mind a discussion between Yann and William about a potential
past issue that could have been re-introduced by a recent optimization.
There was no clear status if it was an issue or not, but if it was, it
would silently be re-introduced.
(I've not been able to find the corresponding mails, will try to dig
further tomorrow evening)
+ clearly document the changes in 2.4 -> 2.5/2.6, to start building the
For me, the main push for this are some of the various async
improvements in trunk that, at least from what I can tell,
simply cannot be backported. It is possible that those improvements
will be the primary and almost-singular distinction between
2.4.x and 2.6.x after all is said and done, but who knows...