apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: [VOTE] Release apr-util 1.4.0
Date Wed, 07 Dec 2011 19:27:08 GMT
On 07 Dec 2011, at 8:17 PM, Jeff Trawick wrote:

> The "People build APR" part is irrelevant.  The versions of autoconf
> and libtool used so far are anything but arbitrary.  They are known to
> work for APR users on a variety of platforms.  You're throwing away
> fixes we have been shipping with for some time, and AFAICT it is not
> practical to evaluate what the real impact is.  (Some AIX level no
> longer recognized?  Some new fooBSD not handled properly?  Who knows?)
> Perhaps the potential concern with apr-util is much less than with apr
> (is it just expat that has nitty gritty considerations?), but I still
> think it is generally wrong to deviate without cause, definitely wrong
> to backlevel, and aggravating to release testers that the
> uninteresting changes to configure-generated files make them hard to
> compare with previous releases.

At some point we have to draw a line, are we releasing apr-util, or are we releasing autoconf/libtool?
We provide a buildconf script so that someone with a problem can regenerate the files, so
I don't think this is a big problem.

And why autoconf v2.64 when the latest is v2.68? And why libtool v1.5.26 when the latest is
v2.4.2? If we're going to avoid vendor deployed versions, I don't see why we should peg ourselves
to obsolete versions of these tools instead.

If we are going to use the native tools instead of vendor tools, we should be using the latest
versions and keep properly up to date.

Another enormous source of frustration is the fact that none of this is documented in a place
that either a browse of the APR development docs or a search in google can find. The process
I followed was to pick apart the svn commits from when v1.3.12 was released, and I discovered
the existence of the release.sh script by accident, stumbling over an archived email message
that referred to it having been moved.

If we intend to encourage others to contribute to this project, and to alleviate the pressure
on the existing people who do releases, we need to make sure that release process is properly
documented and clear.


View raw message