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.
