You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe Jr." <wr...@rowe-clan.net> on 2011/04/15 18:22:55 UTC

Discuss; reset to apr-util 1.5.0-dev?

On 4/15/2011 6:36 AM, Jeff Trawick wrote:
> On Thu, Apr 14, 2011 at 9:51 PM, William A. Rowe Jr.
> <wr...@rowe-clan.net> wrote:
>> In order to disambiguate what was released by external entities from what
>> the ASF APR Project has voted upon and released,
> 
> are you referring to some apr-util-1.4.0 RPM from opensuse.org, or
> something else?

archive.a.o/dist/httpd/httpd-2.3.4-alpha-deps.tar.gz;

   httpd-2.3.4-alpha/srclib/apr-util/include/apr_crypto.h

to be very specific.

It seems prudent to say 'don't trust apu 1.4.0-dev for purposes of compiling
apu_crypto based code, the API you mean to compile against is 1.x.x or later.
But are users expected to test >1.4.0-dev or simply >= 1.4?  I think we promised
the later.

Before we ship 2.0, we have to introduce some mechanism to preview alpha/beta
features, if we don't want to continue this stagnation through the 2.0 lifespan.
Odds/evens versioning might be the solution, but we should come up with some
consensus before 2.0.0 is blessed.

Re: Discuss; reset to apr-util 1.5.0-dev?

Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Friday 15 April 2011, William A. Rowe Jr. wrote:
> On 4/15/2011 6:36 AM, Jeff Trawick wrote:
> > On Thu, Apr 14, 2011 at 9:51 PM, William A. Rowe Jr.
> > 
> > <wr...@rowe-clan.net> wrote:
> >> In order to disambiguate what was released by external entities
> >> from what the ASF APR Project has voted upon and released,
> > 
> > are you referring to some apr-util-1.4.0 RPM from opensuse.org,
> > or something else?
> 
> archive.a.o/dist/httpd/httpd-2.3.4-alpha-deps.tar.gz;
> 
>    httpd-2.3.4-alpha/srclib/apr-util/include/apr_crypto.h
> 
> to be very specific.

>  [X]  Stay at apr-util 1.4.0 for the next pre-2.0 release
>  [ ]  Bump to apr-util 1.4.1 for the next pre-2.0 release
>  [ ]  Bump to apr-util 1.5.0 for the next pre-2.0 release

I really don't think we need to care about compatibility in/with alpha 
tarballs.


> Before we ship 2.0, we have to introduce some mechanism to preview
> alpha/beta features, if we don't want to continue this stagnation
> through the 2.0 lifespan. Odds/evens versioning might be the
> solution, but we should come up with some consensus before 2.0.0
> is blessed.

That sounds like a good idea.