Subversion Tarball Release Procedure ==================================== 1. Tweak trunk/CHANGES to contain all the latest changes. Commit. 2. Bump the version numbers in svn_version.h and CHANGES. Commit. 3. Create the release branch, check out a working copy of the branch, run autogen.sh and ./configure in it. Also, make sure the working copy contains apr, apr-util, neon, and the Docbook tools (XSL, FOP). Those are all needed to build a distribution. (Note that only the release manager commits to the branch; everyone else continues working on trunk, and the release manager ports changes across only if absolutely necessary.) 4. Run './dist.sh [ARGS ...]' (see dist.sh for details about ARGS) Watch dist.sh's output to make sure everything goes smoothly; when it's done, you'll have 'subversion-BLAH.tar.gz' in the cwd. 5. Test the tarball: a) tar xfz subversion-rXXXX.tar.gz; cd subversion-rXXXX b) ./configure --disable-shared --enable-maintainer-mode c) make d) make check e) (start up Apache for testing, then) make davcheck f) (start up svnserve for testing, then) make svncheck g) subversion/clients/cmdline/svn co http://svn.collab.net/repos/svn/trunk 6. [OPTIONAL] Upgrade svn.collab.net to head, then repeat step 5e. Someone with administrative access should do this, usually not the release manager. 7. Post tarball to the "File sharing" section of the tigris.org web site . The ability to upload a public, automatically approved tarball requires the "Project Document - Approve" permission, which is a standard part of the "Download Manager" or "Content Developer" roles. 8. Move branch into the tags directory in the repository. Now that the release is public, no more changes can happen on that branch. If we discover problems with the release, then we make a new branch (with the minor version number incremented), apply fixes, and go through the release process again. 9. Update www/project_status.html on trunk, including a MD5 checksum for the fresh tarball. Commit. 10. Post news item , and send an announcement to dev and announce lists. 11. If necessary, post newest versions of docs to web sites.