On Wed, Dec 7, 2011 at 2:27 PM, Graham Leggett 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 " commit with log "Prepare for the 1.3. 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." (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