Rakudo's development release cycle is based on Parrot's release cycle. Parrot releases the third Tuesday of each month; Rakudo will generally issue its own development release two days after the Parrot release.
Each development release is given a sequential number and a code name based on an active Perl Mongers group. Rakudo's February 2009 release is #14; prior releases were bundled as part of monthly Parrot releases.
2009-02-26 Rakudo #14 "Vienna" (pmichaud) 2009-03-20 Rakudo #15 "Oslo" (pmichaud) 2009-04-23 Rakudo #16 "Bratislava" (pmichaud) 2009-05-21 Rakudo #17 "Stockholm" (pmichaud) 2009-06-18 Rakudo #18 "Pittsburgh" (pmichaud) 2009-07-23 Rakudo #19 "Chicago" (moritz) 2009-08-20 Rakudo #20 "PDX" (kyle) 2009-09-17 Rakudo #21 "Seattle" (particle) 2009-10-22 Rakudo #22 "Thousand Oaks" (duff) 2009-11-19 Rakudo #23 "Lisbon" (masak) 2009-12-17 Rakudo #24 "Seoul" (chromatic) 2010-01-22 Rakudo #25 "Minneapolis" (pmichaud) 2010-02-18 Rakudo #26 "Amsterdam" (mberends) 2010-03-18 Rakudo #27 "Copenhagen" (smash) 2010-04-22 Rakudo #28 "Moscow" (moritz) 2010-05-20 Rakudo #29 "Erlangen" (colomon) 2010-06-17 Rakudo #30 "Kiev" (masak) 2010-07-22 Rakudo #31 "Atlanta" (Coke) 2010-08-19 Rakudo #32 "Pisa" (mathw) 2010-09-23 Rakudo #33 "Milan" (moritz) 2010-10-21 Rakudo #34 "Paris" (duff) 2010-11-18 Rakudo #35 "Melbourne" (masak) 2010-12-23 Rakudo #36 "New York" (smash) 2011-01-20 Rakudo #37 "BristolBath" (tadzik) 2011-02-17 Rakudo #38 "Toulouse" (arnsholt) 2011-03-17 Rakudo #39 "Orlando" (jdhore) 2011-04-21 Rakudo #40 "ZA" (duff) 2011-05-19 Rakudo #41 "Dahut" (jdhore)
Dates are based on Parrot's expected release schedule.
2011-06-23 Rakudo #42 -vacant- 2011-07-21 Rakudo #43 -vacant- 2011-08-18 Rakudo #44 -vacant- 2011-09-22 Rakudo #45 -vacant- 2011-10-20 Rakudo #46 -vacant- 2011-11-17 Rakudo #47 -vacant- 2011-12-22 Rakudo #48 -vacant-
More names can be gotten from http://www.pm.org if you can't think of one with any particular significance to Perl 6 or Rakudo.
Each Rakudo development release is timed to occur two days after a Parrot monthly release.
- A few days before the Parrot release, it's a good idea to...
- Remind people of the upcoming release, invite people to update the ChangeLog file, update the ROADMAP, choose a release name, etc.
- Verify that the Parrot trunk head is able to build Rakudo and run the spectest suite. Also check the smolder reports at http://smolder.parrot.org/app/projects/smoke_reports/5.
- If Parrot's trunk exhibits any problems building or running Rakudo (that require changes to Parrot to fix), immediately report them to the Parrot development team so they can be fixed prior to Parrot's release.
- Review the RT queue for tickets that might need resolving prior to the release, addressing them as needed. "Tickets that need resolving" is left your discretion. Any problem that has a large impact on users is worth addressing either as a fix or as prominent documentation (the README and/or the release announcement).
- Once Parrot issues its monthly release, edit Rakudo's build/PARROT_REVISION file to contain the
git describe --tagsoutput corresponding to Parrot's monthly release. Once
build/PARROT_REVISIONhas been set to the Parrot release, it must not be changed until after the Rakudo release. In other words, we want each monthly release of Rakudo to be able to be built using the immediately prior release of Parrot.
(Old releases required you to add both the version and the
git describeoutput to the PARROT_REVISION file. This is not necessary anymore).
- The short period following the Parrot release until the Rakudo release is generally intended for fixing bugs, updating documentation, and so on.
- Update Rakudo's leap-second tables:
$ perl tools/update-tai-utc.pl src/core/tai-utc.pm
If a new leap second has been announced, tai-utc.pm will be modified, so commit the new version:
$ git commit src/core/tai-utc.pm
But probably there won't be any new leap seconds, in which case the file will be unchanged.
- As the actual release date nears, review the git log history to see if any additional items need to be added to the ChangeLog. This can be conveniently done with "git log --since=yyyy-mm-dd --reverse".
$ git commit docs/ChangeLog
- When it's time to cut the release, create a new release announcement in docs/announce/YYYY.MM. It's often a good idea to use the previous month's file as a starting point for this. Highlight areas in which the new release is significant. If possible, also give some small details about the choice of release name. (If the details are a bit lengthy, this can often best be done as a separate section at the bottom of the announcement.)
Include a list of contributors since the last release in the announcement. You can get an automatically generated list by running
$ perl tools/contributors.pl
Note: this program requires the perl module Date::Simple be installed.
Please check the result manually for duplicates and other errors.
$ git add docs/announce/YYYY.MM $ git commit docs
- Update the release dates and names at the top of this file (docs/release_guide.pod). Also improve these instructions if you find any steps that are missing.
$ git commit docs/release_guide.pod
- Make sure everything compiles and runs from a known clean state:
$ make realclean $ perl Configure.pl --gen-parrot $ make $ make test $ make stresstest
There are many tests to run for the stresstest target. If you have a machine with multiple CPU cores, you may want to execute that last as
$ TEST_JOBS=4 make stresstest
where 4 is the number of CPU cores. This should make the total time to execute all of the tests dramatically less.
Continue adjusting things until make stresstest passes as expected. Often this means fixing a bug, fudging a test, or (temporarily?) commenting out a test file in t/spectest.data . Use your best judgment or ask others if uncertain what to do here.
- Enter the new version into the VERSION file, and commit the changes:
$ echo 2010.09 > VERSION $ git commit -m '[release] bump VERSION' VERSION
- Make sure any locally modified files have been pushed back to github.
$ git status $ git push
- Create a tarball by entering
make release VERSION=YYYY.MM, where YYYY.MM is the month for which the release is being made. This will create a tarball file named <rakudo-YYYY.MM.tar.gz>.
Caution: this step removes any untracked files in t/spec. So please make a backup if you have any important data in there.
- Unpack the tar file into another area, and test that it builds and runs properly using the same process in step 7. If there are any problems, fix them and go back to step 7.
- Tag the release by its release month ("MMMM.YY") and its code name.
$ git tag -a -m"tag release #nn" MMMM.YY # e.g., 2010.02 $ git tag -a -m"tag release #nn" CODENAME # e.g., "Bratislava" $ git push --tags
- Upload the release tarball to github's download area at http://github.com/rakudo/rakudo/downloads.
- To avoid public confusion with Rakudo Star releases, we now publish compiler release announcements ONLY to firstname.lastname@example.org. (We may restart widespread announcements of compiler releases once they are known, or we may begin publishing a single announcement for both.)
- Update the Wikipedia entry at http://en.wikipedia.org/wiki/Rakudo.
- You're done! Celebrate with the appropriate amount of fun.
Copyright (C) 2009-2011, The Perl Foundation.
Hey! The above document had some coding errors, which are explained below:
- Around line 128:
You have '=item 3' instead of the expected '=item 4'
- Around line 142:
You have '=item 4' instead of the expected '=item 5'
- Around line 150:
You have '=item 5' instead of the expected '=item 6'
- Around line 172:
You have '=item 6' instead of the expected '=item 7'
- Around line 180:
You have '=item 7' instead of the expected '=item 8'
- Around line 204:
You have '=item 8' instead of the expected '=item 9'
- Around line 211:
You have '=item 9' instead of the expected '=item 10'
- Around line 218:
You have '=item 10' instead of the expected '=item 11'
- Around line 227:
You have '=item 11' instead of the expected '=item 12'
- Around line 233:
You have '=item 12' instead of the expected '=item 13'
- Around line 241:
You have '=item 13' instead of the expected '=item 14'
- Around line 246:
You have '=item 14' instead of the expected '=item 15'
- Around line 254:
You have '=item 15' instead of the expected '=item 16'
- Around line 258:
You have '=item 16' instead of the expected '=item 17'