Release Instructions

To prepare a release:

0.: Announce to parrot-porters and #parrot at least a couple days in advance, asking if there are any showstopping bugs. It's also good to ask for updates to NEWS, CREDITS, PLATFORMS, RESPONSIBLE_PARTIES, etc. You might also select a name for your release (e.g., perhaps select a name from http://en.wikipedia.org/wiki/List_of_parrots).
1.: Make sure you're up to date:; 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 "Appendix 1".
2.: Update files with version-specific information:
3.: Presuming everything goes well later, you'll need the revision number from this commit, write it down.
4.: Prepare the release tarball.; where a.b.c is the version number. This will create the tarball named parrot-a.b.c.tar.gz. This will automatically avoid including DEVELOPING in the release tarball.
5.: Untar parrot-a.b.c.tar.gz into another area.
6.: Make sure everything works:
7.: Tag the release as "RELEASE_a_b_c", where a.b.c is the version number. If you're working in trunk, be sure to specify the revision number generated in step 3, above.; See also "Appendix 1" below.
8.: In PAUSE, assign yourself co-maintainer permissions on all modules owned by PARROTRE.; Upload to CPAN.; NOTE: you may get a failure message from the CPAN Indexer about the content of META.yml. Don't panic, the tarball still uploaded okay. You do need to fix META.yml for the next release. Under "no_index" list any modules that aren't properly part of the Parrot distribution.; Once you get a reply from the PAUSE indexer, log in to PAUSE to clean up module permissions. Under "View Permissions" search for your PAUSE ID. Any new modules added in this release will list your PAUSE ID as the "owner". Change the owner to PARROTRE.; See docs/project/pause_guide.pod for more details.
9.: Compose and send out the announcements -- parrot-porters, perl6-language, perl6-announce, perl5-porters, use Perl, PerlMonks, etc. Don't forget to include the next scheduled release date.; Use tools/util/crow.pir to make this part easier. You can specify the format of your announcments like so:; Take the screen output and paste it into the application you need. HTML works well for use Perl and PerlMonks, and text for the rest.
10.: Close any release-related tickets in RT. If they are not yet resolved, migrate the critical ones to the next milestone release ticket. Non-critical unresolved tickets can be simply unlinked.
11.: You're done! Help yourself to a beer, cola or other celebratory drink.

ABOUT THIS DOCUMENT

This document was written after a couple of subtly incorrectly assembled releases--usually when someone forgot to delete DEVELOPING (which is now automated!), but at least once where the MANIFEST check failed. The intent of this file is to document what must be done to release so that such mistakes don't happen again.

Appendix 1

parrot repository layout as of end of Apr 2005

 $ svn ls $SVNPARROT
 branches/
 tags/
 trunk/

 $ svn ls $SVNPARROT/tags
 PRE_REL_0_0_8/
 RELEASE_0_0_10/
 RELEASE_0_0_11/
 RELEASE_0_0_13/
 RELEASE_0_0_6/
 RELEASE_0_0_8/
 RELEASE_0_0_9/
 RELEASE_0_1_0/
 RELEASE_0_1_1/
 RELEASE_0_1_2/
 REL_0_0_5/
 V1/
 file_move_031023/
 help/
 ponie-PRE-P5_592/

Releasing from a branch

Instead of step 1, create a new branch, and get a working copy of it:

   $ export SVNPARROT=https://svn.perl.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 svn copy so that you know which changes were made on the branch.

This new 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

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 parrot-release working copy via svn switch by switching it back to the trunk (assuming 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 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. Then go get that beer!

Appendix 2

Planned releases in 2008.

To make a monthly release schedule possible, we're spreading the burden of releases across multiple release managers. Releases are scheduled for the 3rd Tuesday of each month. Version numbers for each release will be determined each month, and will depend on the features that will be in that release.

 - Jan 15th (0.5.2) Bob Rogers
 - Feb 19th (?)     Patrick Michaud
 - Mar 18th (?)     Bernhard Schmalhofer
 - Apr 15th (?)     Jerry Gay
 - May 20th (?)     chromatic
 - Jun 17th (?)     Nuno Carvalho

parrotcode: Untitled
Contents \| Project Information

Release Instructions

ABOUT THIS DOCUMENT

SEE ALSO

Appendix 1

Releasing from a branch

Appendix 2