> -----Ursprüngliche Nachricht----- > Von: William A. Rowe, Jr. > Gesendet: Montag, 14. April 2008 12:49 > An: dev@httpd.apache.org > Betreff: Re: Ship 1.3.0 apr in httpd 2.2.9 > > Ruediger Pluem wrote: > > > > here is my idea: > > > > Ship 1.3.0 with httpd 2.2.x, but do *not* make httpd > dependent on 1.3.x > > now. Wait for this until 1.3.x has settled a bit more and > things like > > the ones Nick mentioned are fixed. > > I'm not entirely keen on this idea; the reasons being > > * we want to pick up 1.3 api's to fix log file creation > 'the right way'
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. > * 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. > > > 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. * 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 > > > But it might be also ok to require the users in these cases > to download > > 1.2.x separately drop in the sources and call buildconf. > > well if there is no difference between 1.2 and 1.3, and we recognize > that the first 1.3.0 is entirely not solving the problem for memcached > for example, we could change the prereq to 1.3.1 for the next release > to ensure they have the bug-free implementation for the next > httpd tag. Sure. I guess this needs to be done anyway regardless of my proposal. Regards Rüdiger
