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
Date Mon, 22 Nov 2004 19:08:24 GMT
At 12:17 PM 11/22/2004, Justin Erenkrantz wrote:

>I expect that as it stands right now most 2.0 modules will compile for 2.2 with very minor
(if any) changes.  If we 'fix' 64-bit issues now, then that means that their modules are going
to undergo massive changes.  

This I will attest to; porting to 2.2 for mod_aspdotnet, I encountered;

  - lost APR_BRIGADE_FOREACH
  - changed apr_pool_get_parent // apr_pool_parent_get

and of course; link to libapr-1 / libaprutil-1.  other than that,
it was very clean.

>That *will* affect the 2.2 uptake rate because our third parties will take a lot of time
to get their modules 64-bit clean (if they do at all).

WHO CARES?!?  That's on them.  They can release bug fixes after
bug fixes, or extend their list of tested/supported platforms
as they get around to it.  It's their problem.

As it stands, WE will be in THEIR WAY with incorrect code in apr
and httpd.  At that point - they cannot address the problems until
we release the next version minor (2.4 or 3.0).  How unfair is that?

>I still think this needs to be punted to 2.4.  It's just *way* too big. 

Way too big for you to handle?  Ok.  Not asking you to develop,
test or even review.

>We'll also have to fix up all of httpd to be 64-bit clean.

Not hard.

>And, that's going to push 2.2 out even further.

It's pointless arguing this aspect.  Are we done with 2.2?  If you
want to vote on 2.2 - then vote on 2.2 - don't get in the way of
other developers' progress with hand waving.  That, I think, is the
biggest lesson I took out of the httpd luncheons.

>This is something we should take our time on - not try to rush out the door and then have
to go back and clean up because we rushed 2.2 (and APR 2.0) out the door.  No thanks.  --
justin

I could say the same about...

...nevermind.  The lesson we learned, in a nutshell;

  When httpd 2.1-dev is mostly satisfactory, and we have an alpha
  that the community decides is ready to take to 2.2 - we fork.
  That fork gets stabilization improvements until it's beta, and
  finally GA quality.  That GA release is titled 2.2.0.

  In the meantime, head becomes 2.3-dev.  Once again, nobody is
  standing in the way of code fixes.  They can be percolated down
  to the 2.2 branch (before or after 2.2.0 is blessed), and even
  all the way to the 2.0 branch.  That requires more review, which
  it should so 'stable' branches don't destabilize.


Mime
View raw message