apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: [VOTE] Time for APR 1.0
Date Tue, 02 Sep 2003 17:46:43 GMT
Justin Erenkrantz wrote:

> I'd like to propose a vote:
> 
> [ ] - Yes, I think we're ready for 1.0 now (in both apr and apr-util)
> [X] - No, I think we're not ready for 1.0 because __________

...there are some trivial things to change prior to 1.0 API freeze, such 
as moving sockaddr_in* to end of apr_sockaddr_info_t, dropping 
deprecated stuff, etc.  Some of the atomic API doesn't make sense (no 
way to compile it in 64-bit mode IIRC) and needs to be fixed (as Brian 
suggested in a follow-up) or dropped.

I would suggest that a 0.9 branch be created from HEAD ASAP for use by 
Apache 2.0.x and any other apps that have to maintain a certain API, 
then we have 7 days to make the changes that were held back until just 
prior to 1.0, then we start talking about a release.

If it is too hard to get the API fixed in 7 days, then it doesn't get 
changed for APR 1.0.  But if it is easy enough to get fixed in a week, 
it has probably been postponed just because we had the notion that there 
would be a gap between the time we abandon 0.9.x compatibility and the 
time 1.0 is available.

I also suggest that we have a week or so long beta period after we say 
we *think* the 1.0 API is ready but before we really release it as 1.0, 
then we can use Apache 2.1-dev and perhaps other big apps as a testbed 
(make whatever changes are needed for APR 1.0 API and give the app some 
testing) to lower the risk that we didn't do anything stupid.

So this adds a week or two to when APR 1.0 would be available.



Mime
View raw message