httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
Subject RE: cvs commit: httpd-2.0/include ap_release.h
Date Wed, 06 Mar 2002 18:16:40 GMT
> Justin Erenkrantz wrote:
> 
> >On Wed, Mar 06, 2002 at 09:48:38AM -0800, Ryan Bloom wrote:
> >
> >>Yes, I have tagged 2.0.33.  I won't roll the release until Aaron
commits
> >>the path problem fix.  I'll announce when the roll is done.
> >>
> >
> >Let me just go on record saying that I don't think we're in a
> >position to release another version.
> >
> >IMHO, we need the API changes in before doing another release.
> >You obviously don't seem to agree with me (per our usual custom).
> >Whatever.  I believe this isn't a good time to be tagging.  We've
> >just had several major changes and we still haven't thoroughly
> >tested their impact yet.
> >
> 
> I agree with Justin on both parts: I'd prefer to get the API
> changes in place (pool allocators and buckets are the ones that
> I know of) and do some more testing on the latest round of filter
> rewrites (are they running on daedalus) before relasing 2.0.33.
> 
> I'd ideally like to see 2.0.33 become the "API freeze" release,
> where we're able to tell 3rd party module maintainers that the
> APIs are now stable, with 2.0.34 following it as the "performance
> tuning and bug fixes" release (and GA candidate).

I'm sorry.  I'm confused.  It seems like we are willing to make SOME
major changes if some people on this list are interested in them.  But
other major changes are a bad idea, even if they fix bugs.

Please, somebody explain to me which changes are allowed to go into the
code, and which aren't?

I have been seeing messages that say we absolutely get a GA release ASAP
and others that say that a GA release must wait until the API's have
frozen.  Of course, by definition, we don't freeze API's in Apache.  For
all intents and purposes, we have been stating that the API's have been
frozen for some time in fact.

So, could somebody explain which code is allowed to change, and which
code isn't?

I realize that this is a VERY sarcastic message.  I am seriously trying
to make a point here.  Either we are developers all pulling towards a
real release, or we aren't.  I believe that we are.  Tagging the tree
today doesn't actually hurt anything it just draws another line and
says, this code is good.  I believe the code is good.  It will be better
by the time I actually roll the release.

Ryan



Mime
View raw message