notes/releases.txt

                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 <http://subversion.tigris.org/servlets/ProjectDownloadList>.
   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 <http://subversion.tigris.org/servlets/ProjectNewsAdd>,
    and send an announcement to dev and announce lists.

11. If necessary, post newest versions of docs to web sites.