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

Re: [PATCH] notes/releases.txt

From: <kfogel_at_collab.net>
Date: 2003-07-15 17:38:50 CEST

This patch is a great idea, Paul, thanks for doing it. Some minor
edits below, for your consideration:

> + 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

Excellent! No comment :-).

> + c. Make sure your release branch wc has the following packages
> + extracted into the root of the wc tree:
> +
> + apr (http://www.apache.org)
> + apr-util (http://www.apache.org)
> + neon (http://www.webdav.org)

Are there more specific URLs for these? If so, giving them here can
save time (or just point to INSTALL, if they're in there).

> + DocBook Tools (see doc/book/README for where/how to install these)
> + XSL Style Sheets (docbook-xsl)
> + http://sourceforge.net/project/showfiles.php?group_id=21935
> +
> + FOP http://xml.apache.org/fop/index.html
> +
> + *ALL* of these are needed to build Subversion.

Are these URLs given in some other document? If so, just point to
that doc, IMHO. That way if we fix it in one place, it's fixed for
all the others.

> + Subversion usually develops against the latest release of the
> + Apache 2.x web server. Therefore, the easiest way to get
> + apr/apr-util is to download the latest release of the httpd
> + source, and use the apr/apr-util trees contained within.
> +
> + $ tar zxvf httpd-2.x.yy.tar.gz
> + $ cd httpd-2.x.yy/srclib
> + $ rsync -rav apr apr-util /path/to/release-X.YY.Z
> +
> + Extract the neon source tar-ball to the same location.
> +
> + Configure httpd-2.x.yy:
> +
> + ./configure --prefix=/path/to/dev/area --enable-so --enable-dav
> + --enable-deflate [--enable-maintainer-mode]
> +
> + make
> + make install

This is all explained in INSTALL, right? Maybe just reference that.

Basically, release managers have to be familiar with installing
Subversion and running all combinations of 'make check'. They might
as well get that familiarity the same way everyone else does, reading
the same docs, etc...

> + Make sure httpd.conf is properly set up for DAV access:
> +
> + <Location /repositories>
> + DAV svn
> + SVNParentPath /path/to/new_release-X.YY.Z/subversion\
> + /tests/clients/cmdline/repositories
> + </Location>
> +
> + <Location /local_tmp/repos>
> + DAV svn
> + SVNPath /path/to/new_release-X.YY.Z/subversion\
> + /tests/clients/cmdline/local_tmp/repos
> + </Location>

This is also a dup of information in INSTALL. Just reference it.

> + d. Run ./autogen.sh

Maybe most of the above could be compressed to

  "See sections 'Building the Latest Source under Unix' and 'BUILDING
   A SUBVERSION SERVER' in the INSTALL file."

:-).

> 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.

Beautiful.

> @@ -20,33 +87,101 @@
> 5. Test the tarball:
> a) tar xfz subversion-rXXXX.tar.gz; cd subversion-rXXXX
> b) ./configure --disable-shared --enable-maintainer-mode
> +
> + ./configure --prefix=/path/to/dev/area
> + --enable-mod-activation
> + --with-apxs=/path/to/apache/bin/apxs
> + --enable-maintainer-mode

Don't say how to build Subversion, INSTALL already says it :-).

> 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)
> + e) make davcheck

Likewise, more or less.

> -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/client/cmdline/README
> +
> + f) make svncheck
>
> + For this step, start up svnserve with special args:
> +
> + $ subversion/svnserve/svnserve -d -r \
> + `pwd`/subversion/tests/clients/cmdline
> +
> + After svnserve is running as a daemon 'make svncheck' should run
> +
> + g) 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

I don't know if this material is already in INSTALL, but perhaps it
should be? The point is, testing is not something only release
managers do...

> 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.

Great!

> -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.
> + - Log into http://subversion.tigris.org
> + - Click on the 'file sharing' link (left frame at the top)
> + - Click on the 'Source tarballs' link (main frame)
> + - Click on the 'Add a file' link (top, main frame, under 'File Sharing')
> + - 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 0.25.0 (MD5: <md5sum of tarball>)
> + Contents: (select 'Attachment', hit Browse or enter path to tarball)
> +
> + - Click Submit

Beautiful...

> + 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.

Very detailed, but probably a good idea to spell it out like this, yes.

> +8. Move branch into the tags directory in the repository.
> +
> + svn mv 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.

Nice description.

> +9. Update www/project_status.html on trunk.
> +
> + Edit the www/project_status.html file appropriately in /trunk *NOT*
> + in the release branch and commit.
> +
> + Then, 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.
> +

Good.

> +
> +12. [OPTIONAL] Upgrade svn.collab.net to head, then repeat step 5e.
> + Someone with administrative access should do this, usually not the
> + release manager.

Good point, that had been confusing, yes.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 15 18:31:53 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.