Plüm wrote:
It has not be the right way for long and the fixes that need to be
done are small. So I see no issue here having this done in 2.2.9 with
apr 1.2.x. We can align it with trunk 2.2.10 or later.
fair enough
* users looking at the mmn expect a certain baseline; explaining why
they cannot compile this module which is purported to run with httpd
ver 2.2.9 or later would become too complicated.
Do we really need a bump anyway when we only ship 2.2.x with 1.3.x but
do not make it dependent on it?
We could do the bump later once we depend on 1.3.x.
this makes things more difficult on third party module authors, but not
saying that makes it impossible.
You are right that we can ship apr-1.3 claiming apr-1.2 readiness, and
bump to 1.3 prereq+mmn bump a bit later.
Furthermore I could image adding apr-1.2.x / apr-util-1.2.x
directories
to our tarballs for the next release to make it easy for
users to fall
back to 1.2.x if there is some kind of regression in 1.3.0.
Now that the code is branched, we should ensure there is fundamentally
no difference in existing 1.2.x functionality; we can't break abi or
even significantly change behaviors, only add "new things"
In general yes. All the measures above should only ensure that the users
have a quick fallback in case something is broken. I still think that
this approach gives us the best of both:
* A broad test audience for 1.3.0 and thus giving us a much better feeling
for the quality of 1.3.x.
goodness, yes
* A very quick possibility to resolve possible regression issues in 1.3.0
Of course these possible regression issues should be solved quickly
1.3..x
yes
let's see what others have to say over the next day or two, if they can
stand the frustration of waiting 2 more months to take advantage of the
api changes.
