On Wed, Dec 7, 2011 at 2:27 PM, Graham Leggett <[email protected]> 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 [email protected] 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 [email protected] 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 [email protected] cc: [email protected] 5. Clean up old after new release is on all mirrors, svn rm old version from release directory
