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.