breser@tigris.org writes:
> Modified: trunk/notes/releases.txt
> ==============================================================================
> --- trunk/notes/releases.txt (original)
> +++ trunk/notes/releases.txt Thu Apr 15 13:14:24 2004
> @@ -1,36 +1,43 @@
> Subversion Tarball Release Procedure
> ====================================
>
> -1. Create a release branch from the "golden" revision number:
> +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 -rHEAD -m"Create release X.Y.Z branch" \
> http://svn.collab.net/repos/svn/trunk \
> - http://svn.collab.net/repos/svn/branches/X.Y.Z
> + http://svn.collab.net/repos/svn/branches/X.Y.x
Since this is about the creation of a long-lived line, it probably
doesn't make sense to call it a "release branch", either in the
explanatory text or the log message.
Hmm, and now that I think about it, do the instructions for creating
long-lived lines belong in releases.txt at all?
And finally :-), wherever they're documented, it's probably worth
pointing out explicitly that "X" and "x" mean very different things in
these examples, since the latter is a literal.
> - (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.)
> + All release of the X.Y line will come out of this branch.
> + Changes from trunk will be merged based upon compatability
> + rules and voting as explained in HACKING.
>
> -2. Tweak trunk/CHANGES to contain all the latest changes.
> +2. Bump the version numbers in svn_version.h on trunk.
Well, not for a 1.0.2 release when trunk is already on 1.1.x, right?
> - a) Begin a new section at the top of the file with:
> + Note that this should be the next major/minor line we plan on doing.
> + E.G. if you're making the 1.1.x branch then the svn_version.h in trunk
> + should reflect 1.2.0.
Hmmm. Yah.
I get the feeling we're mixing two documents here. There's "How do we
maintain different development lines?" (which probably belongs in
HACKING, to the extent that it's not documented there already), and
then there's "How to do a release?", which is only about releasing.
notes/releases.txt should probably confine itself to the latter.
> - Version X.Y.Z (released XX Month 200X, from revision XXXX)
> + 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) Bump the version numbers in svn_version.h and CHANGES.
> -
> - c) Commit.
> + b) Commit.
>
> -3. Create a working copy (wc) from the release branch:
> +4. Create a working copy (wc) from the release branch:
>
> $ svn co http://svn.collab.net/repos/svn/branches/X.Y.Z
>
> -4. The branch stabilizing week
> +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 Dev
> - mailing list.
> + the release branch. A decision of a merge happends in the STATUS
> + file as documented in HACKING.
IMHO, no need for us to talk about the merging guidelines much in
releases.txt. We have a self-sustaining voting system, the release
manager needs to know how it works and be able to evaluate the STATUS
file, but the merges themselves are not part of the release process
per se.
> In the following example, we pretends to merge revision 7868 into
> the release branch:
> @@ -44,14 +51,17 @@
> $ 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:
> + a note under User-visible changes or Developer-visible changes.
> +
> + * fixed: Java bindings compilation.
>
> - Merged revisions after release branching:
> - * r7868 - Java bindings
> + 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.
Nice point.
> d) Commit
>
> -5. It's release time, so cd to the release branch's working copy.
> +6. 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:
> @@ -92,15 +102,16 @@
> (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
> - same way as described in section 4 in this document when merging
> - fixes to the release branch.
> +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.
> +
> +8. Run './dist.sh -v X.Y.Z -r 1234 -pr branches/X.Y.Z'
It's still true that if someone builds an executable from the "release
branch" during the time between this step and the actual release, that
the 'svn --version' output of that executable will be distinguishable
from the 'svn --version' output of the Subversion that gets released
later, right?
> -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.Y.Z.tar.gz' in the cwd.
> + it's done, you'll have 'subversion-X.Y.Z.tar.gz' and
> + 'subversion-X.Y.Z.tar.bz2' in the cwd.
Ah, much needed addition, yes.
> -8. Test the tarball:
> +9. Test the tarball:
> a) tar zxvf subversion-X.Y.Z.tar.gz; cd subversion-X.Y.Z
> b) ./configure
>
> @@ -150,8 +161,12 @@
> 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.
> +10. Use GPG to sign release.
> +
> + [Details to be filled in later].
Yup, but agree it's good to have the placeholder now.
> +11. 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
> @@ -175,18 +190,39 @@
>
> f. Click Submit
>
> -10. Move branch into the tags directory in the repository.
> +12. Copy branch into the tags directory in the repository.
>
> - svn mv -m "Moved Release X.Y.Z branch to tags/." \
> - http://svn.collab.net/repos/svn/branches/X.Y.Z \
> + svn cp -m "Make tag for release X.Y.Z." \
> + http://svn.collab.net/repos/svn/branches/X.Y.x \
> http://svn.collab.net/repos/svn/tags/X.Y.Z
>
> - 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.
> +13. Switch your working copy to the tag.
> +
> + svn switch http://svn.collab.net/respos/svn/tags/X.Y.Z
> +
> +14. Copy svn_version.h.dist (that dist.sh made in the top level of your wc)
> + to subversion/includes/svn_version.h and commit.
> +
> + cp svn_version.h subversion/include/svn_version.h
> + svn commit -m "Update svn_version.h to match tarball." \
> + subversion/include/svn_version.h
> +
> + Now that the release is public and the tag matches the tarball, changes
> + are not allowed on the tag. If we discover problems with the release,
> + then we will fix them on the branch we did the release off of and do a
> + new release.
Ah! Interesting solution. And perfectly fine, IMHO. The point of a
tag is not that it can never have any commits at all, but that there
is a moment after which one can say "There should be no *more* commits".
Rest looks good to me.
Thanks for taking this on; let me know what you think about the
maintaining-a-line vs releasing-a-line distinction.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 15 23:40:47 2004