Subversion Tarball Release Procedure
                ====================================

1.  When starting a new major or minor line create a release branch
    from the "golden" revision number (otherwise skip to step 3):

       svn cp https://svn.collab.net/repos/svn/trunk \
              https://svn.collab.net/repos/svn/branches/X.Y.x \
              -r HEAD \
              -m "Create release X.Y.Z branch"

    All release of the X.Y line will come out of this branch.
    Changes from trunk will be merged based upon compatibility
    rules and voting as explained in HACKING.

2.  Bump the version numbers in svn_version.h on trunk.

    Note that this should be the next major/minor line we plan on
    doing.  For example, if you're making the 1.1.x branch then the
    svn_version.h in trunk should reflect 1.2.0.

    You'll commit this change along with the change in step 3. 

3.  Tweak trunk to have a new CHANGES section.

    a) Begin a new section at the top of the CHANGES file with:

       Version X.Y.Z (released XX Month 200X, from branches/X.Y.Z)
       http://svn.collab.net/repos/svn/tags/X.Y.Z

    b) Commit.

4.  Create a working copy (wc) from the release branch.

       $ svn co https://svn.collab.net/repos/svn/branches/X.Y.Z

5.  Merge fixes and changes from trunk. 

    Only very important bugfixes are allowed to merge from the trunk to
    the release branch. A decision of a merge happends in the STATUS 
    file as documented in HACKING. 

    In the following example, we pretends to merge revision 7868 into
    the release branch:

    a) cd to your branch release working copy and run:
 
       $ svn merge -r7867:7868 https://svn.collab.net/repos/svn/trunk
 
    b) commit the changes:
 
       $ svn ci -m "Merge r7868 into the 0.34.0 branch"
 
    c) cd to your wc for https://svn.collab.net/repos/svn/trunk and add
       a note under User-visible changes or Developer-visible changes. 
 
          * fixed: Java bindings compilation.
 
       Differentiate between client-side and server-side changes by putting
       them in separate sections.
 
       Note: CHANGES is maintained on the trunk because future releases should
       have past releases CHANGES entries.  It will be merged onto the branch
       just before a release.
 
    d) commit

6.  It's release time, so cd to the release branch's working copy.
 
    Make sure your release branch wc has the following packages
    extracted into the root of the wc tree:
 
       apr           (see INSTALL, section I)
       apr-util      (see INSTALL, section I)
       neon          (see INSTALL, section I)
 
    To install apr/apr-util, see INSTALL, section I.1.
 
    To install neon, see INSTALL, section I.5.
 
    To configure/install Apache (httpd-2.X.YY), see INSTALL,
    section I.7 and section III.  If you maintain a separate
    build/release area, and don't want to over-write an
    existing/working installation of Apache, you may want to use
    --prefix=/usr/local/apache2 to install a parallel instance of
    Apache.
 
    To make sure httpd.conf is properly set up for DAV access, see
    subversion/tests/cmdline/README.
 
    You should also have libtool-1.5.14 and autoconf-2.59 installed
    from source.   It is important that you do not use distribution
    shipped versions of this software as they are often patched in
    ways that are not portable.
 
    Also, see sections 'Building the Latest Source under Unix' and
    'BUILDING A SUBVERSION SERVER' in the INSTALL file. for more
    detailed build information.
 
    When building the Windows .zip release be sure to use the apr files
    from the .zip packaging of Apache.  Additionally you'll want to 
    also include the apr-iconv directory from right next to apr-util in
    the Apache zip file.  See INSTALL, section I.1, for details.

7.  Merge CHANGES into the release branch. Do it the same way as
    described in section 4 in this document when merging fixes to the
    release branch.  Make sure the date at the top of CHANGES matches
    the planned release date of the tarball.

8.  Build the tarballs and zip file
 
    a) Run './dist.sh -v X.Y.Z -r 1234 -pr branches/X.Y.Z'
 
       Watch dist.sh's output to make sure everything goes smoothly;
       when it's done, you'll have 'subversion-X.Y.Z.tar.gz' and
       'subversion-X.Y.Z.tar.bz2' in the cwd.
 
    b) Be sure to replace the apr, apr-util and apr-iconv dirs with the 
       ones from the .zip packaging of Apache, before building the .zip,
       as mentioned above in 6.
 
    c) Run './dist.sh -v X.Y.Z -r 1234 -pr branches/X.Y.Z -zip'
 
       Again watch dist.sh's output to make sure everything goes smoothly;
       when it's done, you'll have 'subversion-X.Y.Z.zip' in the cwd.

9.  Test one or both of the tarballs:
 
    a) tar zxvf subversion-X.Y.Z.tar.gz;  cd subversion-X.Y.Z
    b) ./configure
 
       See INSTALL, section III.B for detailed instructions on
       configuring/building Subversion.
 
       If you installed Apache in some place other than the default, as
       mentioned above, you will need to use the same
       --prefix=/usr/local/apache2 option as used to configure Apache.
 
       You may also want to use --enable-mod-activation, which will
       automatically enable the required Subversion modules in the
       Apache config file.
 
    c) make
    d) make check
    e) make install (this activates mod_dav)
    f) make davcheck
 
       For this, start up Apache after having configured according to
       the directions in subversion/tests/cmdline/README.
 
       Make sure, that if you maintain a development installation of
       apache, that you check the config file and update it for the
       new release area where you're testing the tar-ball.
 
       (Unless you rename the tree which gets extracted from the
       tarball to match what's in httpd.conf, you will need to edit
       httpd.conf)
 
    g) make svncheck
 
       First, start up svnserve with these args:
 
          $ subversion/svnserve/svnserve -d -r \
            `pwd`/subversion/tests/cmdline
 
       -d tells svnserve to run as a daemon
       -r tells svnserve to use the following directory as the
          logical file system root directory.
 
       After svnserve is running as a daemon 'make svncheck' should run
 
    h) Then test that you can check out the subversion repository
       with this environment:
 
          subversion/svn/svn co https://svn.collab.net/repos/svn/trunk
 
    i) Verify that the perl and python swig bindings at least compile.
       If you can't do this, then have another developer verify.
 
       (see bindings/swig/INSTALL for details)
 
       Ensure that ./configure detected a suitable version of swig,
       perl, and python.  Then:
 
          make swig-py
          make check-swig-py
          sudo make install-swig-py
 
          make swig-pl
          make check-swig-pl
          sudo make install-swig-pl
 
    j) Verify that the javahl bindings at least compile.
       If you can't do this, then have another developer verify.
 
       (see bindings/java/javahl/README for details)
 
       Ensure that ./configure detected a suitable jdk, and then
       possibly re-run with '--enable-javahl' and '--with-jdk=':
 
          make javahl
          sudo make install-javahl
          make check-javahl

10. Use GPG to sign release. 

    gpg -b --armor subversion-X.Y.Z.tar.gz
    gpg -b --armor subversion-X.Y.Z.tar.bz2
    gpg -b --armor subversion-X.Y.Z.zip

11. Create the tag with the svn_version.h that reflects the final release.
    You do this by updating your working copy to the release revision, 1234 in
    the example below.  Run svnversion to verify that you do not have a mixed
    working copy or modified working copy, i.e. svnversion outputs only the
    release revision (not 1234:1235 or 1234M).  Then place the 
    svn_version.h.dist file in place in the working copy and copy from
    the working copy to the tag URL.

    For example:
      
       svn up -r 1234
       svnversion .
       cp svn_version.h.dist subversion/include/svn_version.h
       svn cp . \
              https://svn.collab.net/repos/svn/tags/X.Y.Z \
              -m "Tagging release X.Y.Z with svn_version.h matching tarball"

    Note: Please always make a tag, even for release candidates.

12. Upload the tarballs to http://subversion.tigris.org/downloads/.

    The RM will be given details on how to do this via private channels.

13. Link to the tarballs from the Downloads page:

       http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=260

    a) Log into http://subversion.tigris.org/
    b) Click on the 'Downloads link (left frame at the top)
    c) Click on the 'Source tarballs' link (main frame)
    d) Click on the 'Add a file' link (top, main frame, under 'File Sharing')
    e) Fill in the following fields:

       Name: subversion-X.Y.Z.tar.gz (replace X.Y.Z with the release number)
       Status: Stable
       Description: Subversion release X.Y.Z (MD5: <md5sum of tarball>)
       Contents: (choose 'Link', then enter
           http://subversion.tigris.org/downloads/subversion-X.Y.Z.tar.gz)

    f) Click Submit

14. Bump the svn_version.h for the original branch.

    Modify subversion/include/svn_version.h.  If you just did 1.0.2
    then svn_version.h should have the proper values for 1.0.3 and so
    on.

15. Update the website.

   a) Edit the www/project_status.html file appropriately in /trunk *NOT*
      in the release branch and commit. Remember edit a search term at the
      end of release's issue link. 

      If you used 'svn switch' in 3b above, you can simply 'switch' back
      to /trunk using:

         svn switch https://svn.collab.net/repos/svn/trunk

      then edit the www/project_status.html file appropriately.

   b) Update the best available version at the top of www/project_packages.html

   c) Commit the modifications.

16. Post news item <http://subversion.tigris.org/servlets/ProjectNewsAdd>,
    and send an announcement to dev@, users@, and announce@ lists.
    Remember to include the URL and MD5 checksums in the announcement!

    Note that the subversion.tigris.org news item is in HTML format not
    plain text.  A tigris.org user with RM or higher status must approve
    the subversion.tigris.org news item.

    For the email to the lists, ensure that your mailer doesn't wrap over
    80 character lines.

    You should also notify freshmeat of the new release:

       http://freshmeat.net/projects/subversion/

    You need to be listed as a release manager or admin on Freshmeat.
    Contact one of the folks listed on the Subversion project page for
    access.  Your submission will also be tweaked by the freshmeat crew
    before it goes public.

17. Someone with administrative access should upgrade svn.collab.net
    to head.  (This is not usually the release manager.)

18. If you've made it this far, go and enjoy your $favorite_beverage now.