You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Justin Erenkrantz <ju...@erenkrantz.com> on 2003/08/31 18:56:12 UTC
[VOTE] Time for APR 1.0
I'd like to propose a vote:
[ ] - Yes, I think we're ready for 1.0 now (in both apr and apr-util)
[ ] - No, I think we're not ready for 1.0 because __________
Personally, I think we're well beyond the point of 1.0 stability, so I'd like
to call what we have now 1.0 and start enforcing our version rules.
Obviously, we'll need to create release candidates to shake out any major bugs
first.
We know what we have isn't 100% perfect, but we have version rules for
addressing how we'll fix things as they come along.
We've had this discussion before and I don't think there was any serious
opposition (other than 'I want my cool feature in 1.0'). So, let's stop
dilly-dallying and get 1.0 out the door. -- justin
Re: [VOTE] Time for APR 1.0
Posted by Jeff Trawick <tr...@attglobal.net>.
Max Bowsher wrote:
> On Tue, 2 Sep 2003, Jeff Trawick wrote:
>
>>somebody want to sanity check this before I screw everything up?
>>
>>$ cd apr
>>$ cvs tag -b -r HEAD -R APR_0_9_X
>>$ cd ../apr-util
>>$ cvs tag -b -r HEAD -R APR_0_9_X
>
>
> Previous apr-util tags have used the prefix "APU_", not "APR_".
thanks for catching that
Re: [VOTE] Time for APR 1.0
Posted by Max Bowsher <ma...@ukf.net>.
On Tue, 2 Sep 2003, Jeff Trawick wrote:
>
> somebody want to sanity check this before I screw everything up?
>
> $ cd apr
> $ cvs tag -b -r HEAD -R APR_0_9_X
> $ cd ../apr-util
> $ cvs tag -b -r HEAD -R APR_0_9_X
Previous apr-util tags have used the prefix "APU_", not "APR_".
Max.
Re: [VOTE] Time for APR 1.0
Posted by Jeff Trawick <tr...@attglobal.net>.
Cliff Woolley wrote:
> On Tue, 2 Sep 2003, Jeff Trawick wrote:
>
>
>>somebody want to sanity check this before I screw everything up?
>>
>>$ cd apr
>>$ cvs tag -b -r HEAD -R APR_0_9_X
>>$ cd ../apr-util
>>$ cvs tag -b -r HEAD -R APR_0_9_X
>
>
> Looks basically right to me. Nits: If you're already up-to-date with
> HEAD, you don't have to specify -r HEAD. And if it were me, I'd call it
> APR_0_9_BRANCH rather than _0_9_X, but nbd.
APR_0_9_BRANCH it is, as soon as the heat pump guy and the door guy leave.
RE: [VOTE] Time for APR 1.0
Posted by Sander Striker <st...@apache.org>.
> From: Cliff Woolley [mailto:jwoolley@virginia.edu]
> Sent: Tuesday, September 02, 2003 9:52 PM
> On Tue, 2 Sep 2003, Jeff Trawick wrote:
>> somebody want to sanity check this before I screw everything up?
>>
>> $ cd apr
>> $ cvs tag -b -r HEAD -R APR_0_9_X
>> $ cd ../apr-util
>> $ cvs tag -b -r HEAD -R APR_0_9_X
>
> Looks basically right to me. Nits: If you're already up-to-date with
> HEAD, you don't have to specify -r HEAD. And if it were me, I'd call it
> APR_0_9_BRANCH rather than _0_9_X, but nbd.
+1 on all of the above, including naming it APR_0_9_BRANCH.
Sander
Re: [VOTE] Time for APR 1.0
Posted by Cliff Woolley <jw...@virginia.edu>.
On Tue, 2 Sep 2003, Jeff Trawick wrote:
> somebody want to sanity check this before I screw everything up?
>
> $ cd apr
> $ cvs tag -b -r HEAD -R APR_0_9_X
> $ cd ../apr-util
> $ cvs tag -b -r HEAD -R APR_0_9_X
Looks basically right to me. Nits: If you're already up-to-date with
HEAD, you don't have to specify -r HEAD. And if it were me, I'd call it
APR_0_9_BRANCH rather than _0_9_X, but nbd.
--Cliff
Re: [VOTE] Time for APR 1.0
Posted by Jeff Trawick <tr...@attglobal.net>.
Justin Erenkrantz wrote:
> --On Tuesday, September 02, 2003 13:46:43 -0400 Jeff Trawick
> <tr...@attglobal.net> wrote:
>
>> 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.
>
>
> +1. Go for it. ;-) -- justin
somebody want to sanity check this before I screw everything up?
$ cd apr
$ cvs tag -b -r HEAD -R APR_0_9_X
$ cd ../apr-util
$ cvs tag -b -r HEAD -R APR_0_9_X
???
Re: [VOTE] Time for APR 1.0
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Tuesday, September 02, 2003 13:46:43 -0400 Jeff Trawick
<tr...@attglobal.net> wrote:
> 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.
+1. Go for it. ;-) -- justin
Re: [VOTE] Time for APR 1.0
Posted by Jeff Trawick <tr...@attglobal.net>.
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.
Re: [VOTE] Time for APR 1.0
Posted by Ben Collins-Sussman <su...@collab.net>.
[X] - Yes, I think we're ready for 1.0 now (in both apr and apr-util)
[ ] - No, I think we're not ready for 1.0 because __________
Re: [VOTE] Time for APR 1.0
Posted by Aaron Bannert <aa...@clove.org>.
>> [X] - Yes, I think we're ready for 1.0 now (in both apr and apr-util)
>> [ ] - No, I think we're not ready for 1.0 because __________
My belated 2 cents,
-aaron
Re: [VOTE] Time for APR 1.0
Posted by Cliff Woolley <jw...@virginia.edu>.
On Sun, 31 Aug 2003, Justin Erenkrantz wrote:
> [X] - Yes, I think we're ready for 1.0 now (in both apr and apr-util)
> [ ] - No, I think we're not ready for 1.0 because __________
Re: [VOTE] Time for APR 1.0
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
> Depending on just how hastily you want to tag a release,
> I'd like to clean up the apr_atomic API prior to 1.0.
Personally, I'd like to see the first APR 1.0 release candidate out by the
end of this week. At that point, I'd like to see whatever API is included
in there frozen for 1.0 (barring a major deficiency that we agree *must*
be fixed prior to 1.0).
I'd also have no problems with this atomics change by then. If you aren't
comfortable with making that change this quickly, then I'd suggest waiting
for the next release cycle.
I just don't want to see us delay any further. -- justin
Re: [VOTE] Time for APR 1.0
Posted by Brian Pane <br...@cnet.com>.
On Sun, 2003-08-31 at 09:56, 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)
> [ ] - No, I think we're not ready for 1.0 because __________
Depending on just how hastily you want to tag a release,
I'd like to clean up the apr_atomic API prior to 1.0.
Currently, the interface is inconsistent: some functions
operate on apr_uint32_t, while others operate on
apr_atomic_t. I'd like to deprecate the current API
and switch to a new API that looks something like this:
apr_uint32_t apr_atomic_read32(volatile apr_uint32_t *mem);
apr_uint32_t apr_atomic_add32(volatile apr_uint32_t *mem,
apr_uint32_t val);
apr_uint32_t apr_atomic_cas32(volatile apr_uint32_t *mem,
apr_uint32_t with,
apr_uint32_t cmp);
Brian
Re: [VOTE] Time for APR 1.0
Posted by "B. W. Fitzpatrick" <fi...@red-bean.com>.
Justin Erenkrantz <ju...@erenkrantz.com> writes:
> I'd like to propose a vote:
>
> [X] - Yes, I think we're ready for 1.0 now (in both apr and apr-util)
> [ ] - No, I think we're not ready for 1.0 because __________
-Fitz
--
Brian W. Fitzpatrick <fi...@red-bean.com> http://www.red-bean.com/fitz/
Re: [VOTE] Time for APR 1.0
Posted by Thom May <th...@planetarytramp.net>.
* Sander Striker (striker@apache.org) wrote :
> > From: Justin Erenkrantz [mailto:justin@erenkrantz.com]
> > Sent: Sunday, August 31, 2003 6:56 PM
>
> > I'd like to propose a vote:
> >
> > [X] - Yes, I think we're ready for 1.0 now (in both apr and apr-util)
> > [ ] - No, I think we're not ready for 1.0 because __________
>
+1
>
> Sidenote, are we tossing all those deprecated APIs before rolling
> the 1.0 tarball? (drop the compat wrappers etc.)
>
I think we should, else we'll be carrying them around for ever.
-Thom
RE: [VOTE] Time for APR 1.0
Posted by Sander Striker <st...@apache.org>.
> From: Justin Erenkrantz [mailto:justin@erenkrantz.com]
> Sent: Sunday, August 31, 2003 6:56 PM
> I'd like to propose a vote:
>
> [X] - Yes, I think we're ready for 1.0 now (in both apr and apr-util)
> [ ] - No, I think we're not ready for 1.0 because __________
Sidenote, are we tossing all those deprecated APIs before rolling
the 1.0 tarball? (drop the compat wrappers etc.)
Sander