[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

[PATCH] notes/releases.txt (take 2)

From: <pll_at_lanminds.com>
Date: 2003-07-16 22:12:00 CEST

* notes/releases.txt

  Updated to expand the directions for people unfamiliar with the
  particulars of release management as the differ from a normal
  development environment.

Index: releases.txt
===================================================================
--- releases.txt (revision 6492)
+++ releases.txt (working copy)
@@ -5,48 +5,179 @@
 
 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.)
+3. Create the release branch for building the release:
 
+ a. Create the branch
+
+ svn cp -rHEAD -m"Create release-X.YY.Z branch" \
+ http://svn.collab.net/repos/svn/trunk \
+ http://svn.collab.net/repos/svn/branches/release-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.)
+
+ b. Check out a working copy of the branch
+
+ svn co http://svn.collab.net/repos/svn/branches/release-X.YY.Z
+
+ or
+
+ svn switch http://svn.collab.net/repos/svn/branches/release-X.YY.Z
+
+ if you have an existing working copy
+
+ c. 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)
+ DocBook Tools (see doc/book/README)
+
+ *ALL* of these are needed to build Subversion.
+
+ 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=/path/to/dev/area 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.
+
+ d.
+
+ Also, see sections 'Building the Latest Source under Unix' and
+ 'BUILDING A SUBVERSION SERVER' in the INSTALL file. for more
+ detailed build information.
+
+ d. Run ./autogen.sh
+
 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.
+ it's done, you'll have 'subversion-X.YY.Z.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
+ 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=/path/to/dev/area 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) (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
+ e) make install (this activates mod_dav)
+ f) make davcheck
 
-6. [OPTIONAL] Upgrade svn.collab.net to head, then repeat step 5e.
- Someone with administrative access should do this, usually not the
- release manager.
+ For this, start up Apache after having configured according to
+ the directions in subversion/tests/clients/cmdline/README.
+
+ g) make svncheck
 
+ For this step, 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
+
 7. Post tarball to the "File sharing" section of the tigris.org web
- site <http://subversion.tigris.org/servlets/ProjectDownloadList>.
+ 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.
+ roles. If you don't have this access, make sure you
+ 'Request a New Role' from the tigris web site.
 
-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.
+ Once Download Manager status has been granted:
 
-9. Update www/project_status.html on trunk, including a MD5 checksum
- for the fresh tarball. Commit.
+ a. Log into http://subversion.tigris.org
+ b. Click on the 'file sharing' 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: <md5sum of tarball>)
+ Contents: (select 'Attachment', hit Browse or enter path to tarball)
+
+ f. Click Submit
+
+ To get the MD5 checksum for the tarball, make sure you have the
+ md5sum command installed and from the release branch wc, run:
+
+ md5sum subversion-X.YY.Z.tar.gz
+
+ There will be a single line of 2 fields returned looking something like:
+
+ $ md5sum subversion-0.25.tar.gz
+ a018220d5c790161bc712ccb7d0f1b38 subversion-0.25.tar.gz
+
+ The 32 character alpha-numeric string on the left is the checksum.
+ Use this in the Description field, and also mention it in the
+ Announcement e-mail explained below.
+
+8. Move branch into the tags directory in the repository.
+
+ svn mv http://svn.collab.net/repos/svn/branches/release-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.
+
+9. Update www/project_status.html on trunk.
+
+ a. Edit the www/project_status.html file appropriately in /trunk *NOT*
+ in the release branch and commit.
+
+ 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 and commit.
+
+ b. Go to http://svn.collab.net and click on the "Update the
+ live web site" link. Click 'Publish' then visit
+ http://subversion.tigris.org/project_status.html to make sure
+ the changes are there. You may have to hit 'Reload' if this
+ page was previously visited, and therefore cached by your
+ browser.
+
 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.
+
+12. [OPTIONAL] Upgrade svn.collab.net to head, then repeat step 5e.
+ Someone with administrative access should do this, usually not the
+ release manager.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 16 22:13:02 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.