Skip to content
Find file
Fetching contributors…
Cannot retrieve contributors at this time
223 lines (154 sloc) 6.58 KB

release_guide.pod - guide to Rakudo releases

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.

Development 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)

Planned 2009 releases

Dates are based on Parrot's expected release schedule.

  2009-09-17   Rakudo #21 "Seattle"            (particle)
  2009-10-22   Rakudo #22                      (duff)
  2009-11-19   Rakudo #23                      (masak)
  2009-12-17   Rakudo #24                      (chromatic)
  2010-01-21   Rakudo #25                      (smash)
  2010-02-18   Rakudo #26                      (Su-Shee)

Suggested .pm group names for future releases (

Steps to create a release (for release managers)

Each Rakudo development release is timed to occur two days after a Parrot monthly release.

  1. 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.
    • 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).
  2. Once Parrot issues its monthly release, edit Rakudo's build/PARROT_REVISION file to contain the subversion revision number and release number corresponding to Parrot's monthly release. For example, for June 2009 PARROT_REVISION file contained "39599 1.3.0". As always, test to make sure Rakudo still builds and passes its tests. Once build/PARROT_REVISION has 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.
  3. The short period following the Parrot release until the Rakudo release is generally intended for fixing bugs, updating documentation, and so on.
  4. 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
  5. 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.)

    The release announcement has a bullet for passing spectests and the percentage of the available spectest suite that's passing. To get the number of available tests, look at "docs/spectest-progress.csv". If it hasn't been updated recently, use "git log docs/spectest-progress.csv" to find out who has been updating it and seek out this person for an update. You can also run tools/ to obtain the latest data. To get the total number of available spectests, the tool ack (see has to be installed and be found in $PATH.

    As of this writing, there's not a publicly available tool to update spectest-progress.csv or to count tests that won't run.

      $ git add docs/announce/YYYY-MM
      $ git commit docs
  6. 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
  7. Make sure everything compiles and runs from a known clean state:
      $ make realclean
      $ perl --gen-parrot
      $ make
      $ make test
      $ make spectest

    Continue adjusting things until make spectest passes as expected. Often this means fixing a bug, fudging a test, or removing a test from t/ . Use your best judgement or ask others if uncertain what to do here.

  8. Make sure any locally modified files have been pushed back to github.
      $ git status
      $ git push
  9. Create an initial 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 candidate tarball file named <rakudo-YYYY-MM.tgz>.
  10. Unpack the tar file into another area, and test that it builds and runs properly. If there are any problems, fix them and go back to step 7.
  11. Tag the release by its release month ("MMMM-YY") and its code name.
      $ git tag -a -m"tag release #nn" MMMM-YY    # e.g., 2009-04
      $ git tag -a -m"tag release #nn" CODENAME   # e.g., "Bratislava"
      $ git push --tags
  12. Upload the release tarball to github's download area at
  13. Publish the release announcement (from #5) above to appropriate locations, including, use.perl, perl6-language, perl6-announce, perl6-users, and others.
  14. Update the Wikipedia entry at
  15. Promote the release anywhere else you think appropriate.
  16. You're done! Celebrate with the appropriate amount of fun.


Copyright (C) 2009, The Perl Foundation.

Jump to Line
Something went wrong with that request. Please try again.