apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: [VOTE] Release apr-util 1.4.0
Date Wed, 07 Dec 2011 20:12:16 GMT
On Wed, Dec 7, 2011 at 2:27 PM, Graham Leggett <minfrin@sharp.fm> wrote:
> 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.

We are releasing apr-util *and* the outputs of autoconf/libtool.

A flawed output of autoconf/output occasionally requires end-users to
run buildconf as a work-around, but that situation is still considered
a project issue to try to address for the next release.

> 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.

httpd needed changes to fix warnings with autoconf 2.68, but that
doesn't mean apr* needs help.  IIRC, using some libtool 2.x has been
tested before with apr or httpd and discovered to be harmful for some
reason, but I can't quickly find that discussion.

> 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.

It is certainly a Good Thing to further document/codify how it is done
to remove unintended variations when different individuals roll the
tarballs.

FWLIW, I did the same thing before I rolled the first time -- look at
the svn commits.  Comparing my generated tarballs/zips with the ones
from the previous release was also instructive.

My own cookbook, below, specifies the steps in a level of detail far
beyond what is required or would be generally considered the work of a
sane person, and also references a few private scripts which also are
very specific to my workflow and directory layout.

(Change apr to apr-util as appropriate; similar for version numbers.)


0. Make sure signing key is in APR KEYS file

0. Review changes since the last release; fix or ask about anything
   suspicious.

0. Make sure APR test suite runs as well as expected on Windows.

0. Check Windows command-line build.

1. Tagging

a. pre-tag edits

   apr_version.h (or apu_version.h)

   everything but APR_IS_DEV_VERSION should already be correct
   comment out APR_IS_DEV_VERSION   (or APU_IS_DEV_VERSION)

   STATUS

   add new version with ": in development on branches/1.3.x/"
   change old version to say ": tagged <today's date>"

   commit with log "Prepare for the 1.3.<NEWNUMBER> tag"; use rev as
   XXXXXX below

b. tag

   svn copy -rXXXXXX https://svn.apache.org/repos/asf/apr/apr/branches/1.3.x \
       https://svn.apache.org/repos/asf/apr/apr/tags/MAJOR.MINOR.SUBVER

       (or apr-util)

   use commit msg "Tag MAJ.MIN.SUBVER"

c. post-tag edits

   CHANGES

   add new entry "Changes for APR 1.3.<NEXTNUMBER>"

        (or APR-Util ....)

   apr_version.h     (or apu_version.h)

   increment APR_PATCH_VERSION        (or APU_...)

   uncomment APR_IS_DEV_VERSION       (or APU_xxx)

   commit with msg "1.3.10 is tagged; bump to 1.3.11 (development)"

2. Rolling

   check for GNU tools versions
     apr-1.3.12: autoconf 2.64, libtool 1.5.26

   use apr-site/tools/release.sh
   make sure gpg-agent is running

   SIGNING-USER is trawick@apache.org

   compare with tarballs of previous release to check for unexpected differences

   test signatures and sums via chksumfiles.sh

3. Publish as test

   svn co https://dist.apache.org/repos/dist/dev/apr apr-dev

   Edit copy-apr-targets.sh to fix
     NEWVER
     MAJMIN
     COMP
     CHANGES
   Run copy-apr-targets.sh script from rolling directory
    to copy correct files to $HOME/svn/apr-dev and add as
    appropriate

   Commit as "Proposed $PROJECT-$VERSION"

   commit to dev/dist
   announce on dev@apr.apache.org


4. Release, after release is tested/approved

   a. Step 1: Get mirrors populated.

   move tarballs from dev/apr to https://dist.apache.org/repos/dist/release/apr/
     (run apr-mv-dev-release.sh to generate the command, which then has to
     be executed via cut-and-paste)

   Commit as "Binding +1 for release: {list of user ids}"

   update CHANGES-APR-1.3 Announcement13.{txt,html}, README.html, HEADER.html
      in /dist/release/apr

   remove CHANGES-APR-1.3 from /dist/dev/apr

   b. Step 2: After mirrors are populated:

   in apr site:
     edit/commit xdocs/download.xml, xdocs/index.xml, docs/download.html,
                 docs/index.html, doap.rdf

                 when the current MAJ.MIN changes or for some other reason
                 the left-hand navigation needs to be tweaked, edit
                 xdocs/stylesheets/project.xml

   update STATUS file to indicate when it was released

   Send out announcement to announce@apache.org cc: dev@apr.apache.org

5. Clean up old

   after new release is on all mirrors, svn rm old version from
   release directory

Mime
View raw message