To prepare a release:
- Announce to parrot-porters and #parrot at least a couple days in advance,
asking if there are any showstopping bugs.
You might also select a name for your release (e.g.,
perhaps select a name from http://en.wikipedia.org/wiki/List_of_parrots).
- Make sure you're up to date:
$ 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 before releasing, rather than after. Then you could fold the release-oriented changes into the trunk once the release is done.
- TODO: explain how to do this
- Update files with version-specific information:
- Increment the version number in the following files: VERSION, parrot.spec, MANIFEST.generated, META.yml, README.
- Also update the version number, date, and your name in the following files: DEVELOPING, docs/parrothist.pod, and docs/ROADMAP.pod
- Update ChangeLog, NEWS with the new version number and any other changes that have occurred since the last release: Hopefully these files are being updated as committers work.
- Update release-related information in tools/util/release.json. This will be used later when making release announcements. There are a few interesting fields:
- Create a new ticket for the next release. Change the URL fragment here to use that ticket's number.
- Open the link to the previous value of this field. Copy the resulting full URL, then change the ticket number in the
DependedOnBy parameter to the ticket for the next release. Take the entire resulting URL to http://xrl.us/ and get a short URL. Add that to this field.
- Make sure RESPONSIBLE_PARTIES is still accurate.
- Configure parrot and run
perl t/harness t/distro/*.t, and either fix what those tests complain about, or fix them so they don't complain.
- Update PBC_COMPAT, perhaps by collapsing intra-release entries into a single entry naming the release.
perl tools/dev/pbc_header.pl --upd t/native_pbc/*.pbc to update version and fingerprint in the native tests.
- Make sure everything works:
$ make realclean
$ perl Configure.pl --test ...
$ make -s all world fulltest html
# Note that fulltest runs separate harnesses..
- Prepare the release tarball.
$ make release VERSION=a.b.c
- 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.
- Untar parrot-a.b.c.tar.gz into another area.
- Make sure everything works:
$ perl Configure.pl
$ make world
$ make fulltest
- 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.
$ export SVNPARROT=https://svn.perl.org/parrot
$ svn copy -m"tagged release a.b.c" \
- See also "Appendix 1" below.
- Upload to CPAN.
- NOTE: you may get a failure message from the CPAN Indexer about the content of META.yml. Don't worry, the tarball still uploaded okay. You can fix META.yml after the release. (TODO: clarify what this means)
- 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:
$ parrot tools/util/crow.pir --type=text
$ parrot tools/util/crow.pir --type=html
- 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.
- Submit the use Perl announcement story to Slashdot, Newsforge, etc. Don't forget to set a Reply-To: or Followup-To: header, if your mail client lets you.
- Modify the topic on #parrot, e.g.:
/topic #parrot Parrot 0.4.8 Released | http://parrotcode.org/
- Update the next planned release date on the wiki.
- Update the website. The svn repository for the website is at https://svn.perl.org/perl.org/docs/live/parrotcode.
- Add a release announcement to news/[year]/Parrot-[release].html. Update
/index.html (The old mini-announcement may be commented out). Update
/source.html. Make sure all urls are updated appropriately.
- Test locally in combust before pushing update out.
- Close any release-related tickets in RT. If they are not yet resolved, migrate them to the next milestone release ticket.
- You're done! Help yourself to a beer, cola or other celebratory drink.
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.
parrot repository layout as of end of Apr 2005
$ svn ls $SVNPARROT
$ svn ls $SVNPARROT/tags
Planned releases in 2007.
To make a monthly release schedule possible, we're spreading the burden of releases across multiple release managers. Each release manager takes one release in a 6 month rotation. Releases are scheduled for the 3rd Tuesday of the month.
- Jan 16th (0.4.8) Jerry Gay (particle)
- Feb 20th (0.4.9) Patrick Michaud (pmichaud)
- Mar 20th (0.4.10) Will Coleda (Coke)
- Apr 17th (0.4.11) Matt Diephouse (mdiep)
- May 15th, chromatic
- Jun 19th, Allison Randal
- Jul 17th, Jerry Gay (particle)
- Aug 21th, Patrick Michaud (pmichaud)
- Sep 18th, Matt Diephouse (mdiep)
- Oct 16th, Will Coleda (Coke)
- Nov 20th, chromatic
- Dec 18th, Allison Randal
Hey! The above document had some coding errors, which are explained below:
- Around line 67:
- Deleting unknown formatting code U<>