[svn:parrot] r37426 - trunk/docs/project

allison at svn.parrot.org allison at svn.parrot.org
Sun Mar 15 03:15:45 UTC 2009


Author: allison
Date: Sun Mar 15 03:15:44 2009
New Revision: 37426
URL: https://trac.parrot.org/parrot/changeset/37426

Log:
[release] Standardize on one release process instead of two (safer,
repeatable, and tested every month).

Modified:
   trunk/docs/project/release_manager_guide.pod

Modified: trunk/docs/project/release_manager_guide.pod
==============================================================================
--- trunk/docs/project/release_manager_guide.pod	Sun Mar 15 00:30:30 2009	(r37425)
+++ trunk/docs/project/release_manager_guide.pod	Sun Mar 15 03:15:44 2009	(r37426)
@@ -39,10 +39,7 @@
  $ svn update
 
 You may want to ask the developer base to stop committing big changes;
-it will avoid complications.  Or you could create a release branch,
-make release-related changes there, and fold them back into the trunk
-once the release is done. This process is explained in
-L<Appendix 1|"Appendix 1 - Releasing from a branch">.
+it will avoid complications.
 
 =item 2.
 
@@ -163,8 +160,6 @@
  $ svn copy -m "tagged release a.b.c" \
    $SVNPARROT/trunk $SVNPARROT/tags/RELEASE_a_b_c
 
-See also L<Appendix 1|"Appendix 1 - Releasing from a branch"> below.
-
 =item 8.
 
 SSH to ftp-osl.osuosl.org. (If you don't have the necessary login information,
@@ -329,57 +324,7 @@
 
 F<README>, F<RESPONSIBLE_PARTIES>.
 
-=head1 Appendix 1 - Releasing from a branch
-
-Instead of step 1, create a new branch, and get a working copy of it:
-
-   $ export SVNPARROT=https://svn.parrot.org/parrot
-   $ svn copy -m"Starting release a.b.c" \
-              $SVNPARROT/trunk $SVNPARROT/branches/RELEASE_a_b_c
-   $ svn checkout $SVNPARROT/branches/RELEASE_a_b_c parrot-release
-   $ cd parrot-release
-
-Make a note of the revision number produced by C<svn copy> so that you
-know which changes were made on the branch.
-
-This new C<parrot-release> working copy will be "on" the branch,
-insulated from trunk commits, so you should feel free to announce the
-end of any "code slush" that may be in effect.
-
-Then, do steps 3 through 7 using your branch working copy, so that
-commits go to the branch.  When you are sure that the tarball is all
-that it should be, tag the release as a copy from the branch (instead
-of the trunk):
-
-   $ svn copy -m"Release a.b.c" \
-           $SVNPARROT/branches/RELEASE_a_b_c $SVNPARROT/tags/RELEASE_a_b_c
-
-Alternatively you can also move the branch:
-
-   $ svn move -m "Tagging release a.b.c" \
-           $SVNPARROT/branches/RELEASE_a_b_c $SVNPARROT/tags/RELEASE_a_b_c
-
-Upload your shiny new tarball, announce the release, and close tickets
-(steps 9 through 11) as described above.
-
-Finally (don't get your celebratory drink yet!), you need to merge the
-branch changes back into the trunk.  To do this, you need an
-up-to-date working copy on the trunk.  You can reuse the
-C<parrot-release> working copy via C<svn switch> by switching it back
-to the trunk (assuming C<parrot-release> is the current directory):
-
-   $ svn switch $SVNPARROT/trunk
-
-Then, merge the branch changes back into it:
-
-   $ svn merge -r 12345:HEAD $SVNPARROT/branches/RELEASE_a_b_c
-
-where "12345" is the revision number of the C<svn copy> operation that
-created the branch.  Check that the merge was clean, "make test" if
-there were any code changes on the branch, and commit.  I<Then> go get
-that beer!
-
-=head1 Appendix 2 - Upcoming releases
+=head1 Appendix 1 - Upcoming releases
 
 To make a monthly release schedule possible, we're spreading the burden
 of releases across multiple release managers.  Releases are scheduled for


More information about the parrot-commits mailing list