Subversion Tarball Release Procedure ==================================== 1. Create a release branch from the "golden" revision number: svn cp -rHEAD -m"Create release X.YY.Z branch" \ http://svn.collab.net/repos/svn/trunk \ http://svn.collab.net/repos/svn/branches/X.YY.Z (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.) 2. Tweak trunk/CHANGES to contain all the latest changes. a) Begin a new section at the top of the file with: Version X.YY.Z (released XX Month 200X, from revision XXXX) http://svn.collab.net/repos/svn/tags/X.YY.Z b) Bump the version numbers in svn_version.h and CHANGES. c) Commit. 3. Create a working copy (wc) from the release branch: $ svn co http://svn.collab.net/repos/svn/branches/X.YY.Z 4. The branch stabilizing week Only very important bugfixes are allowed to merge from the trunk to the release branch. A decision of a merge happends in the Dev mailing list. 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 http://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 http://svn.collab.net/repos/svn/trunk and add a note under the merge section like this in the CHANGES file: Merged revisions after release branching: * r7868 - Java bindings d) Commit 5. It's release time, so cd to the release branch's working copy. a) 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/clients/cmdline/README. Also, see sections 'Building the Latest Source under Unix' and 'BUILDING A SUBVERSION SERVER' in the INSTALL file. for more detailed build information. b) Run './autogen.sh && ./configure' so the design docs can get built in the branch tree (in step 4, dist.sh will move the built design docs into the release sandbox). c) Grab the latest prebuilt book from http://svnbook.red-bean.com/ cd doc/book/book wget http://svnbook.red-bean.com/book.pdf wget http://svnbook.red-bean.com/book.html cd ../../.. (The book maintainers keep those files up to date, so the release manager doesn't have to rebuild the book.) 6. Merge CHANGES and svn_version.h into the release branch. Do it the the same way as described in section 4 in this document when merging fixes to the release branch. 7. 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-X.YY.Z.tar.gz' in the cwd. 8. Test the tarball: a) tar zxvf subversion-X.YY.Z.tar.gz; cd subversion-X.YY.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/clients/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/clients/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/clients/cmdline/svn co \ http://svn.collab.net/repos/svn/trunk 9. Upload the tarball to /usr/www/docroot/tarballs/ on svn.collab.net, then link to it from subversion.tigris.org. 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. If you don't have this access, make sure you 'Request a New Role' from the tigris web site. Once Download Manager status has been granted: 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.YY.Z.tar.gz (replace X.YY.Z with the release number) Status: Stable Description: Subversion release X.YY.Z (MD5: ) Contents: (Link, then enter http://svn.collab.net/tarballs/subversion-X.YY.Z.tar.gz) f. Click Submit 10. Move branch into the tags directory in the repository. svn mv http://svn.collab.net/repos/svn/branches/X.YY.Z \ http://svn.collab.net/repos/svn/tags/X.YY.Z \ -m"Moved Release X.YY.Z branch to tags/." 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. 11. 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 http://svn.collab.net/repos/svn/trunk then edit the www/project_status.html file appropriately. b) Commit the modifications of www/project_status.html c) Remind someone with an @collab.net address to update the live web site (we used to have a servlet for this, but at the moment we don't). 12. Post news item , and send an announcement to dev@, users@, and announce@ lists. Remember to include the URL and MD5 checksum in the announcement. 13. Someone with administrative access upgrade svn.collab.net to head. (This is not usually the release manager.)