Browse files

[release_guide] remove redundancy with nqp's release guide

Also split bumping of VERSION and NQP_REVISION into separate steps
  • Loading branch information...
1 parent d90f671 commit 4b2c1fe272051896fd0da6368a4a5bb7c63fb5c9 @moritz moritz committed Jun 24, 2012
Showing with 15 additions and 46 deletions.
  1. +15 −46 docs/release_guide.pod
@@ -117,21 +117,11 @@ the release announcement).
=item 2.
-Once Parrot issues its monthly release, tag NQP for release
-according to the year and month of the release:
- $ git clone
- $ cd nqp
-Follow the steps in NQP's F<docs/release_guide.pod>.
-=item 3.
The short period following the Parrot release until the
Rakudo release is generally intended for fixing bugs,
updating documentation, and so on.
-=item 4.
+=item 3.
Update Rakudo's leap-second tables:
@@ -147,15 +137,15 @@ will be unchanged.
B<Note>: this program requires the perl module L<Time::y2038> be installed.
-=item 5.
+=item 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
-=item 6.
+=item 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
@@ -211,52 +201,31 @@ judgment or ask others if uncertain what to do here.
=item 9.
-=over 4
-=item *
-B<Note>: these steps overlap with the steps in NQP's release guide.
-Go to the NQP repository, bump C<VERSION>, tag it and push the tags
- $ echo YYYY.MM > VERSION
- $ git commit -m 'bump VERSION' VERSION
- $ git push origin master
- $ git tag -a -m"tag release YYYY.MM" YYYY.MM # e.g., 2010.02
-Check the NQP revision
- $ git describe # should come out as YYYY.MM
- # if not, contact your local git vendor or #perl6
-If you got the same version back as you entered, proceed with
+Create an NQP release with the same C<YYYY.MM> version number
+as Rakudo. Follow NQP's C<docs/release_guide.pod> file to do that.
- $ git push --tags
-=item *
+=item 10.
Go back to the Rakudo repository, and update the NQP dependency:
$ echo YYYY.MM > tools/build/NQP_REVISION
$ git commit -m '[release] bump NQP revision' tools/build/NQP_REVISION
-=item *
+=item 11
Enter the new version into the F<VERSION> file, and commit the changes:
$ git commit -m '[release] bump VERSION' VERSION
-=item 10.
+=item 12.
Make sure any locally modified files have been pushed back to github.
$ git status
$ git push
-=item 11.
+=item 13.
Create a tarball by entering C<make release VERSION=YYYY.MM>,
where YYYY.MM is the month for which the release is being made.
@@ -265,38 +234,38 @@ This will create a tarball file named C<rakudo-YYYY.MM.tar.gz>.
B<Caution>: this step removes any untracked files in F<t/spec>.
So please make a backup if you have any important data in there.
-=item 12.
+=item 14.
Unpack the tar file into another area, and test that it
builds and runs properly using the same process in step 8.
If there are any problems, fix them and go back to step 8.
-=item 13.
+=item 15.
Tag the release by its release month ("YYYY.MM") and its code name.
$ git tag -a -m"tag release #nn" YYYY.MM # e.g., 2010.02
$ git tag -a -m"tag release #nn" CODENAME # e.g., "Bratislava"
$ git push --tags
-=item 14.
+=item 16.
Upload the release tarball to github's download area at
-=item 15.
+=item 17.
To avoid public confusion with Rakudo Star releases, we now publish
compiler release announcements ONLY to
(We may restart widespread announcements of compiler releases
once they are known, or we may begin publishing a single
announcement for both.)
-=item 16.
+=item 18.
Update the Wikipedia entry at L<>.
-=item 17.
+=item 19.
You're done! Celebrate with the appropriate amount of fun.

0 comments on commit 4b2c1fe

Please sign in to comment.