apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
Date Sat, 20 Nov 2004 16:27:17 GMT
At 08:23 AM 11/20/2004, Jim Jagielski wrote:

>On Nov 20, 2004, at 12:03 AM, Justin Erenkrantz wrote:
>>So, my opinion is that we let Allen branch apr off now and let him go at it at a measured
pace, but we shouldn't intend to hold httpd 2.2 for that.  -- justin
>+1. Of course, I am assuming that his 64bit fixes will likely
>break binary compatibility. 

It does - that's the rub.  And, for 2.2, this was always the plan.

>For module writers it's not a big deal, but for commercial 
>3rd party modules it might be.  Simply because they would 
>need to produce yet another version of their modules for httpd.

They will.  Implicit in the '2.0 isn't a moving target' comes
the correlary '2.1-dev is a moving target, and once we get it
right, it will be 2.2 and quit shifting the API beneath you.'

>Recall how long it took for some 1.3 modules to be ported to 2.0? 
>With 2.2 they will now need to "port" to 2.2, which obviously is 
>trivially easier than going from 1.3->2.0.

Yes - though there will be api changes as well.  We obviously
need to move beyond APR 0.9 - either to 1.x or (if we have to
fix the API) to 2.x.

>But there will be delay. If we then produce another 2.x which 
>isn't binary compatible, then it's another process and the module 
>list will start looking quite crowded [...]
>That's a lot of modules for companies to worry about.

We might, or it might be too drastic (event mpm's which allow
requests to jump threads.)  If they are too radical for 2.4 or
2.6 expectations, then 3.0 comes along.

I'd hope no faster than 6-18 mos per minor bump because you
are right - it creates a burden for module authors.

>No, I don't have the answer but we should be prepared for
>the uptake of 2.2 to be less than we hope or imagine.

Of course.  This is true of most projects, Major bump is quite
slow (initially), minor is a noticeable delay, and subver should
be quick if we keep it painless.

>This kind of brings up an idea that's been sloshing around between
>that handful of neurons in my noggin: Some sort of API "seed"
>program within httpd/apr where we put a little more effort in
>getting the latest API versions out there. We've been
>operating on a "pull me" scenario, and it's worked, but
>it's been hardly optimal. Maybe some sort of "push"
>mechanism would be useful. Even if it's just a blurb on
>the site that Apache 2.2 will be released soon, here is
>the new API (which is frozen), if you plan to have your
>Apache modules ready for 2.2 when released, please grab
>this tarball and test.

I'm 100% with you - we should loudly scream "The alpha is
here!"  Tell module authors "this is it - if we can make
your life easier, now is the moment we will break ABI in
order to do so!"  Of course, snooze you lose, if there is
something you needed, it will just wait until 2.3-dev for
us to begin work after the feature/api freeze 2.2.


View raw message