Skip to content
Browse files

Improved release manager guide.

  • Loading branch information...
1 parent 78f0dab commit b5fc8a08e9db03b5896af94c28270c3caceb86a2 @soh-cah-toa soh-cah-toa committed
Showing with 207 additions and 199 deletions.
  1. +207 −199 docs/project/release_manager_guide.pod
View
406 docs/project/release_manager_guide.pod
@@ -1,75 +1,77 @@
# Copyright (C) 2007-2011, Parrot Foundation.
-=head1 Release Manager Guide
+=head1 RELEASE MANAGER GUIDE
-To prepare a release:
+The need for this document arised after a couple of improperly assembled
+releases. The intent of this guide is to describe what must be done to
+prepare for a release so that such mistakes won't happen again.
-=head2 I. Preparation during Month before Release
+=head2 I. Preparations During the Month Before a Release
=over 4
=item 1
-As soon as you become the release manager: review the goals for the release on
-the Parrot roadmap (L<https://trac.parrot.org/parrot/roadmap>) and
-announce the tasks to the Parrot mailing list. Make sure everyone knows what
-they've committed to accomplish in time for the release.
+As soon as you become the release manager, review the goals for the release on
+the Parrot roadmap (L<http://trac.parrot.org/parrot/roadmap>) and announce the
+tasks to the C<parrot-dev> mailing list. Make sure everyone knows what they've
+committed to accomplish in time for the release.
=item 2
Right after the release preceding your release, it is a good idea to start
-tracking parrot news in ChangeLog. A good resource are the reports
-in the weekly #parrotsketch IRC-meeting. A reliable log of these meetings
-is available in L<http://irclog.perlgeek.de/parrotsketch/>.
+tracking Parrot news in F<ChangeLog>. A good resource are the individual reports
+posted in the weekly IRC meeting on C<#parrotsketch>. A complete log of these
+meetings is available at L<http://irclog.perlgeek.de/parrotsketch/>.
=item 3
-A couple of weeks in advance: Ask people to run C<make fulltest> and
-report (and hopefully fix!) any problems they find. Check in with
-language project leads for release blockers, to allow time to fix them.
-Also ask people to review the tickets targeted for the upcoming release
-L<https://trac.parrot.org/parrot/roadmap>.
+A couple of weeks in advance, ask people to run C<make fulltest> and
+report (and hopefully fix!) any problems they find. Check in with language
+project leaders (e.g. Rakudo) for potential release blockers to allow time to
+fix them. Also ask people to review the tickets targeted for the upcoming
+release (L<https://trac.parrot.org/parrot/roadmap>).
=item 4
-In the course of the release you will need to be able to log in and operate on
-two different servers. To oversimplify a bit, you will need to be able to
-execute these two commands and their C<scp> equivalents.
+During the course of the release process, you will need to be able to log in
+and operate on two different servers. To oversimplify a bit, you will need to be
+able to execute these two commands and their C<scp> equivalents.
=over 4
=item * C<ssh parrot@ftp-osl.osuosl.org>
-Make sure your SSH key(s) have been added to the FTP server
-C<ftp-osl.osuosl.org>. You can open a support ticket for this by sending an
-email to C<support@osuosl.org> with your SSH keys as attachments.
-Without the key you won't be able to ship the release.
+Make sure your public SSH key(s) have been added to the FTP server
+L<ftp-osl.osuosl.org>. You can open a support ticket for this by sending
+an email to C<support@osuosl.org> with your public SSH keys as attachments.
+Without them, you won't be able to ship the release.
=item * C<ssh E<lt>usernameE<gt>@parrot.org>
-Set up your account on L<http://www.parrot.org/>. Any previous release
-manager may be able to help you, but you may also need to open a support
-ticket at C<support@osuosl.org> in order to be added to the C<parrot> group.
-The C<parrot> group has permissions to create the new directories needed to
-hold documentation for new releases.
+Set up your account on L<http://parrot.org/>. Any previous release manager may
+be able to help you but you may also need to open a support ticket at
+C<support@osuosl.org> in order to be added to the C<parrot> group. The C<parrot>
+group has permissions to create the new directories needed to hold documentation
+for new releases.
=back
=item 5
-A couple of days in advance: announce the new release to
-C<parrot-dev@lists.parrot.org> and to the IRC channel #parrot. Ask whether
+A couple of days in advance, announce the new release to
+C<parrot-dev@lists.parrot.org> and to the IRC channel C<#parrot>. Ask whether
there are any showstopping bugs. Check in again with the language
project leads. It's also good to ask for updates to F<ChangeLog>, F<CREDITS>,
F<PLATFORMS>, F<RESPONSIBLE_PARTIES>, F<api.yaml> and
-L<https://trac.parrot.org/parrot/wiki/Languages>.
+L<http://trac.parrot.org/parrot/wiki/Languages>.
=item 6
-On the Saturday before a release you should notify other developers to stop
-committing non-release related code to trunk. This will help avoid
+On the Saturday before a release, you should notify other developers to stop
+committing non-release related code to the master branch. This will help avoid
complications. They are of course free to commit to branches as much as
-they like. You might also set the topic in #parrot, announcing the
+they like. You might also set the topic in C<#parrot>, announcing the
time when you plan on starting the release procedure. This will help
the committers with timing their last minute commits.
@@ -81,31 +83,32 @@ L<http://en.wikipedia.org/wiki/List_of_parrots>.
=item 8
-NOTE: Build a recent version of Parrot to have available during the release
-to help with bootstrapping. You must have a version of Parrot built and
-available to you for some of the subsequent steps.
+B<NOTE:> You must have a recent version of Parrot already built for some of the
+subsequent steps.
=back
-=head2 II. Check C<git> Status
+=head2 II. Get the Most Recent Changes
-The day of the release has come.
-Make sure you have the most recent version of the master branch:
+The day of the release has come. Make sure you have the most recent version of
+the master branch checked out:
- git checkout master && git pull --rebase
+ git checkout master
+ git pull --rebase
-Also be sure you do not have any local commits that have not yet
-been pushed out and tested thoroughly. You can check for this with
+Also, make sure you do not have any local commits that have not yet been pushed
+and tested thoroughly. You can do so by running:
git log origin/master..
-If there is no output from that command, then your local master
-and the master on origin are in sync.
+If there is no output from that command, then your local master and the remote
+master are in sync.
-=head2 III. Update Version
+=head2 III. Update the Release Version
-Update files with version-specific information, but before doing this you
-should have parrot configured and have run C<make> with the old version:
+Update files with version-specific information but before doing so, you
+should already have configured Parrot (C<perl Configure.pl>) and ran C<make>
+with the old version.
=over 4
@@ -115,52 +118,46 @@ should have parrot configured and have run C<make> with the old version:
=item a
-Use C<tools/release/update_version.pl> to update the version string in a
-several files.
+Use C<tools/release/update_version.pl> to update the version string in
+several files:
- perl tools/release/update_version.pl 3.7.0
+ perl tools/release/update_version.pl 3.8.0
-=item b
-
-B<IMPORTANT:> The version change you just effected by running
-F<tools/release/update_version.pl> effectively invalidates existing generated
-bytecode. Assuming, as is likely, that you ran C<update_version.pl> in a
-directory with an existing build, you must next run C<make reconfig> to clear
-out this now invalid bytecode. (Note that this script takes care of modifying
-generated code, so C<make bootstrap-ops> is no longer necessary for the
-release process.)
+B<IMPORTANT:> The version change you just made by running
+F<tools/release/update_version.pl> invalidates any existing generated bytecode.
+Assuming that it was run in a directory with an existing build, you must now
+run C<make reconfig> to clear out any invalid bytecode.
=item c
-Also update the version number, date, and your name in the
-the file: F<docs/parrothist.pod>.
+Update the version number, date, and your name in F<docs/parrothist.pod>.
=item d
-Update this file, that is F<release_manager_guide.pod>,
-to remove the pending release you're in the middle of.
+Update this file (F<docs/project/release_manager_guide.pod>) to remove the
+pending release you're currently building.
=back
=item 2
-Update F<ChangeLog> 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. If not, it's probably a good idea
-to gather the updates weekly rather than waiting until the day of the
-monthly release.
+Update F<ChangeLog> 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. If not, it's probably a good idea to gather the updates weekly
+rather than waiting until the day of the release.
=item 3
Update release-related information in F<tools/release/release.json>. This will
-be used later when making release announcements. There are a few essential
+be used later when making release announcements. There are a few essential
fields that must be updated at each release:
=over 4
=item C<release.*>
-The date of the next release is in L<Appendix 1|"Appendix 1 - Upcoming releases">.
+The date of the next release (see
+L<Appendix 1|"Appendix 1 - Upcoming Releases">).
=item C<bugday.date>
@@ -168,7 +165,7 @@ Enter the date of the Saturday before the next release.
=item C<wiki.bugday>
-Update the date part of the link to the wiki page for the next bugday.
+Enter the date part of the link to the wiki page for the next bugday.
=item C<ftp.path>
@@ -186,48 +183,48 @@ Give yourself credit for the release in F<CREDITS>.
=item 6
-Configure parrot and run C<make distro_tests>, and either fix
-what those tests complain about, or fix them so they don't complain.
+Configure Parrot and run C<make distro_tests>. Then either fix what those
+tests complain about or fix the tests so that they don't complain.
=item 7
-If this is a developer release, or there have been no new entries to the
-F<PBC_COMPAT> file, skip this step.
+B<NOTE:> You may skip the following step if this is a developer release or
+there have been no new entries to F<PBC_COMPAT>.
-If this is a supported release, and new entries to F<PBC_COMPAT> have been
-added since the last supported release, make a new entry with a new major
-version number for this release at the top of the list.
+If this is a supported release and new entries to F<PBC_COMPAT> have been
+added since the last supported release, add a new entry with a new major
+version number for this release at the top of the list:
3.0 2007.10.17 coke released 0.4.17
-Delete all minor version numbers since the last major bytecode version number,
+Delete all minor version numbers since the last major bytecode version number
as these are only used in development and not relevant to the bytecode support
-policy. (Those changes are all included within the major version number
-increase for the supported release.)
+policy. Those changes are all included within the major version number
+increase for the supported release.
-Once you've updated PBC_COMPAT, running C<sh tools/dev/mk_packfile_pbc> if
-necessary, then run C<sh tools/dev/mk_native_pbc> to update the pbc files used
-in the native pbc tests. Note that you must have Parrot already built for
-this to work, and that this script will reconfigure and rebuild Parrot with
-various primitive size options.
+Once you've updated F<PBC_COMPAT> - running C<sh tools/dev/mk_packfile_pbc> if
+necessary - then run C<sh tools/dev/mk_native_pbc> to update the PBC files used
+in the native PBC tests. Note that you must have Parrot already built for this
+to work and that this script will reconfigure and rebuild Parrot with various
+primitive size options.
=item 8
-Make sure everything works:
+Verify that the build process runs smoothly:
make realclean
perl Configure.pl --test ...
make world html 2>&1 | tee make_world_html.log
make fulltest 2>&1 | tee make_fulltest.log
-Note that running "make fulltest" takes a while and that separate
-harnesses are being run.
+Note that running C<make fulltest> takes a while and that separate harnesses
+are being run.
=back
-=head2 IV. Commit Changes
+=head2 IV. Push Changes to the GitHub Repository
-When all is well, then commit your changes:
+When all is well, commit your changes:
git diff
git add file1 file2 ...
@@ -235,26 +232,27 @@ When all is well, then commit your changes:
Instead of adding files individually, you can also tell C<git commit> that you
want all modified and deleted files to be in your next commit via the C<-a>
-flag:
+switch:
git commit -a -m "awesome and informative commit message"
-Be careful with C<git commit -a>, it could add files that you do not mean to
+Be careful with C<git commit -a> as it could add files that you do not mean to
include. Verify that the contents of your most recent commit look sane with:
git show
-If you want you can note the SHA1 from this commit.
+If you want, you can note the SHA-1 digest from this commit by running:
git rev-parse master > SHA1_TO_REMEMBER
-Update repository on github.
+Update repository on GitHub:
git push origin master
-=head2 V. Prepare Tarballs
+=head2 V. Prepare the Release Tarballs
-Prepare and test the release tarball. There are two possible approaches:
+There are two possible approaches to preparing and testing the release tarball:
+using C<make release> or using C<make release_check>.
=over 4
@@ -264,21 +262,25 @@ Prepare and test the release tarball. There are two possible approaches:
=item a
-Call:
+Begin by running:
make release VERSION=a.b.c
-where a.b.c is a version number like C<3.6.0>. This will create the tarball
-named F<parrot-a.b.c.tar.gz>. This will automatically avoid including
-C<DEVELOPING> in the release tarball.
+where a.b.c is the version number (e.g. C<3.8.0>). This will create the tarball
+named F<parrot-a.b.c.tar.gz>. The F<DEVELOPING> file is automatically excluded
+from the release tarball.
=item b
-Untar F<parrot-a.b.c.tar.gz> into another area.
+Extract F<parrot-a.b.c.tar.gz> into another directory:
+
+ cp parrot-a.b.c.tar.gz ~/another/directory
+ cd ~/another/directory
+ tar -xvzf parrot-a.b.c.tar.gz
=item c
-Make sure everything works:
+Verify that the build process runs smoothly:
perl Configure.pl
make world html 2>&1 | tee make_world_html.log
@@ -288,84 +290,87 @@ Make sure everything works:
=item 2 Via C<make release_check>
-As an alternative, 5 and 6 above, you may wish to call:
+As an alternative, you can package the release by running:
perl Configure.pl
make release_check
-This target (or, for short, C<make relcheck>), will prepare the tarballs, copy
-the F<.gz> tarball to a temporary directory, and then reconfigure, rebuild,
-retest (through C<make test>) and rerelease.
+This target (or, for short, C<make relcheck>), will prepare the tarball, copy it
+into a temporary directory, and then reconfigure, rebuild, re-test
+(with C<make test>) and re-release.
=back
Whichever of these two approaches you take, verify that the version is correct
-and does B<not> contain the suffix C<devel>:
+and B<does not> contain the suffix C<devel>:
./parrot -V
-=head2 VI. Tag Release
+=head2 VI. Tag the Release Commit
-Tag the release as "RELEASE_a_b_c", where a.b.c is the version number.
+Tag the release as "RELEASE_a_b_c", where a.b.c is the version number:
git tag RELEASE_a_b_c
git push --tags
-=head2 VII. FTP Server
+=head2 VII. Push Tarballs to the FTP Server
-Log in to ftp-osl.osuosl.org.
+Log in to L<ftp-osl.osuosl.org>:
ssh parrot@ftp-osl.osuosl.org
-(As noted above, your SSH public key must be added to the list
-of authorized keys before you can log in.)
+As mentioned previously, your public SSH key must be added to the list of
+authorized keys before you can log in.
-If the release is a monthly development release, create a new directory under
-F<~/ftp/releases/devel>.
+If this is a development release, create a new directory under
+F<~/ftp/releases/devel>:
mkdir ~/ftp/releases/devel/a.b.c
-If the release is in the supported series (L<Appendix 1 - Upcoming releases>)
-create the new directory in F<~/ftp/releases/supported> instead.
+If this is a supported release, (see
+L<Appendix 1|"Appendix 1 - Upcoming Releases>), create the new directory in
+F<~/ftp/releases/supported> instead:
mkdir ~/ftp/releases/supported/a.b.c
-Copy the different compressed tarballs and the according checksum files from
-your machine into the new directory.
+Copy all the tarballs and their respective digest files from your machine into
+the new directory:
scp parrot-a.b.c.tar.gz \
parrot-a.b.c.tar.bz2 \
parrot-a.b.c.tar.gz.sha256 \
parrot-a.b.c.tar.bz2.sha256 \
- parrot@ftp-osl.osuosl.org:~/ftp/releases/devel/a.b.c/
+ parrot@ftp-osl.osuosl.org:~/ftp/releases/devel/a.b.c
-(Or use whatever tool you prefer.)
+You don't necessarily have to use C<scp> for this step. You can use whichever
+tool you prefer.
When you're finished making changes, run the trigger script to push the changes
-out to the FTP mirrors.
+out to the FTP mirrors:
- ~/trigger-parrot
+ ~/trigger-parrot
-Check your changes at F<ftp://ftp.parrot.org/pub/parrot/releases>. It should
+Verify your changes at F<ftp://ftp.parrot.org/pub/parrot/releases>. It should
only take a few minutes for the mirrors to sync.
=head2 VIII. Release Announcement
-Compose the release announcement. Use F<tools/release/crow.pir> to make
-this part easier. You can specify the format of your announcements like so:
+Compose the release announcement. Use F<tools/release/crow.pir> to make this
+part easier. You can specify the format of your announcements like so:
- ./parrot tools/release/crow.pir --type=text
- ./parrot tools/release/crow.pir --type=html
+ ./parrot tools/release/crow.pir --type=text
+ ./parrot tools/release/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. It is not a bad idea
-to add a "highlights" section to draw attention to major new features, just be
-sure to say the same thing in both text and HTML versions.
+Copy the output and paste it into the application you need. HTML works well for
+Perl and PerlMonks, and text for the rest. It's a good idea (although not
+necessary) to add a "highlights" section to draw attention to major new
+features. If you do, be sure to say the same thing in both text and HTML
+versions.
-Be sure to include the SHA1 sums of the tarballs in the release announcement;
-They're automatically generated by C<make release>.
+Be sure to include the SHA1 sums of the tarballs in the release announcement
+which are automatically generated by C<make release>.
-=head2 IX. Update Website
+=head2 IX. Update the Website
Update the website. You will need an account with editor rights
on L<http://www.parrot.org>.
@@ -374,82 +379,82 @@ on L<http://www.parrot.org>.
=item 1
-Add a new page for the release announcement with "Create content" -> "Story".
-There's some additional stuff needed at the top of the page; use one of the
+Create a new page for the release announcement by navigating to I<Create content>
+-> I<Story>. There's some additional stuff needed at the top of the page; use one of the
old announcements as a guide.
-The "<!--break-->" line marks the end of the text that will appear on the
-front page.
+The "<!--break-->" line marks the end of the text that will appear on the front page.
=item 2
For the "News" category, select both "Releases" and "News".
Add tags to the page for significant changes in this release (e.g. "rakudo"
-for significant Rakudo language updates, or "gc" for significant garbage
+for significant Rakudo language updates or "gc" for significant garbage
collection subsystem updates).
=item 3
-Under "URL path settings" uncheck "Automatic alias" and set the path to
-news/[year]/Parrot-[release number].
+Under I<URL path settings>, uncheck I<Automatic alias> and set the path to
+I<news/[year]/Parrot-[release number]>.
=item 4
-Under "Publishing options" make sure "Published" and "Promoted to front page"
-are checked.
+Under I<Publishing options>, make sure I<Published> and I<Promoted to front
+page> are both checked.
=item 5
-Under "Administer" -> "Site building" -> "URL Redirects", change the URL for
-"release/current" to the FTP file for the new release (for example,
-F<ftp://ftp.parrot.org/pub/parrot/releases/devel/0.8.1/parrot-0.8.1.tar.gz>).
-Also update the URL for "release/developer" or "release/supported" depending
+Under I<Administer> -> I<Site building> -> I<URL Redirects>, change the URL for
+C<release/current> to the FTP file for the new release (e.g.
+F<ftp://ftp.parrot.org/pub/parrot/releases/devel/3.8.0/parrot-3.8.0.tar.gz>).
+Also update the URL for C<release/developer> or C<release/supported> depending
on which type of release this is.
=item 6
-Update docs.parrot.org. Run C<make html> in a release copy of parrot, and save
-the F<resources/> and F<html/> directories created in F<docs/>. ssh into the parrotvm,
-and in the webroot for docs.parrot.org, expand these into a release directory
-(e.g. 1.4.0). in <webroot>/parrot, there are symbolic links for latest,
-supported, and devel. Update the C<latest> symlink to point to your new
-directory. If this is a supported release, also update the C<supported>
-symlink. Do not delete any old copies of the docs, don't update the other
-symlinks.
+Update L<http://docs.parrot.org>. Run C<make html> in a release copy of Parrot,
+and save the F<resources/> and F<html/> directories created in F<docs/>. Use
+SSH to login to L<< <username>@parrot.org >> and expand these into a release
+directory (e.g. 3.8.0) in the webroot for L<http://docs.parrot.org>. In
+C<< <webroot>/parrot >>, there are symbolic links for C<latest>, C<supported>,
+and C<devel>. Update the C<latest> symlink to point to your new directory. If
+this is a supported release, also update the C<supported> symlink. Do not
+delete any old copies of the docs and don't update the other symlinks.
-=back
+=item 7
Preview the new page, and submit it.
-(The old release announcement may be edited to uncheck "Promoted to front page"
-to keep the main page fresh.)
+=back
+
+The old release announcement may be edited to uncheck I<Promoted to front page>
+to keep the main page fresh.
=head2 X. Publicity
-Publicize the release by publishing the announcement through the
-following channels (and any others you can think of):
+Publicize the release by publishing the announcement through the following
+channels (and any others you can think of):
=over 4
=item 1
-Send a text email to parrot-dev, parrot-users, perl6-language, perl6-announce,
-perl5-porters, etc. (Note: perl6-internals is no longer in use, so you don't
-need to mail that list.) You should also include LWN.net in this mailing;
-email to C<lwn> at that domain.
+Send a text email to C<parrot-dev>, C<parrot-users>, C<perl6-language>,
+C<perl6-announce>, C<perl5-porters>, etc. You should also include L<lwn.net> in
+this mailing; email to C<lwn> at that domain.
=item 2
-Submit the use Perl announcement story to use Perl, Perl Monks, Slashdot,
-Newsforge, etc. Don't forget to set a Reply-To: or Followup-To: header, if
-your mail client lets you.
+Submit the announcement story to use Perl, Perl Monks, Slashdot, Newsforge,
+etc. Don't forget to set a C<Reply-To:> or C<Followup-To:> header, if your mail
+client lets you.
=item 3
-Modify the topic on #parrot, e.g.:
+Modify the topic on C<#parrot>:
- /topic #parrot Parrot 0.4.8 Released | http://parrot.org/
+ /topic #parrot Parrot 0.4.8 Released | http://parrot.org/
=item 4
@@ -466,59 +471,62 @@ Update the C2 wiki entry at L<http://c2.com/cgi/wiki?ParrotCode>.
=back
-=head2 XI. Review Milestones
+=head2 XI. Review the Milestones
Review the milestone for the current release in Trac at
-L<https://trac.parrot.org/parrot/roadmap>. Close any completed
-release-related tickets. Edit the milestone to mark it as "Completed".
-Marking a milestone as completed will migrate all open tickets to a
-selected milestone (generally the next milestone). Non-critical tickets
-can have their milestone unset.
+L<http://trac.parrot.org/parrot/roadmap> and mark it as I<Completed>. Marking a
+milestone as I<Completed> will migrate all open tickets to a selected milestone
+(generally the next milestone). Non-critical tickets can have their milestone
+unset.
+
+Also make sure to close any completed release-related tickets.
=head2 XII. Changes to Trac
-Add the version to Trac so new bug reports can be filed against the release.
-L<https://trac.parrot.org/parrot/admin/ticket/versions>.
+=over 4
+
+=item 1
+
+Add the latest version to Trac so that new bug reports can be filed against the
+release. L<https://trac.parrot.org/parrot/admin/ticket/versions>.
+
+=item 2
+
+Make the latest version the default version for new reports.
-Make the latest released version the default version for new reports.
+=item 3
Remove any sufficiently old versions listed there.
+=back
+
=head2 XIII. Finish
You're done! Help yourself to a beer, cola, or other celebratory drink.
-=head1 ABOUT THIS DOCUMENT
-
-This document was written after a couple of subtly incorrectly assembled
-releases--usually when someone forgot to delete F<DEVELOPING> (which is now
-automated!), but at least once where the F<MANIFEST> check failed. The intent
-of this file is to document what must be done to release so that such mistakes
-won't happen again.
-
=head1 SEE ALSO
F<README>, F<RESPONSIBLE_PARTIES>.
-=head1 Appendix 1 - Upcoming releases
+=head1 Appendix 1 - Upcoming Releases
-To make a monthly release schedule possible, we spread the burden of
-releases across multiple release managers. Releases are scheduled for
-the 3rd Tuesday of each month.
+To make a monthly release schedule possible, we spread the burden of releases
+across multiple release managers. Releases are scheduled for the 3rd Tuesday of
+each month.
The starred releases are Parrot's quarterly supported releases, see
F<docs/project/support_policy.pod>.
-The calendar of releases is available at the comp.lang.parrot google calendar,
-visible at
+The calendar of releases is available at the C<comp.lang.parrot> Google
+calendar, visible at
L<http://www.google.com/calendar/render?cid=ldhctdamsgfg5a1cord52po9h8@group.calendar.google.com>.
-Versions with a asterisk (*) are supported releases.
+Versions with an asterisk (*) are supported releases:
- - Sep 20, 2011 - 3.8 - soh_cah_toa
- - Oct 18, 2011 - 3.9* - dukeleto
- - Nov 15, 2011 - 3.10 - ??
- - Dec 20, 2011 - 3.11 - cotto
+ - Sep 20, 2011 - 3.8 - soh_cah_toa
+ - Oct 18, 2011 - 3.9* - dukeleto
+ - Nov 15, 2011 - 3.10 - ??
+ - Dec 20, 2011 - 3.11 - cotto
=cut

0 comments on commit b5fc8a0

Please sign in to comment.
Something went wrong with that request. Please try again.