# Copyright (C) 2007-2009, The Perl Foundation.
# $Id: /mirror/trunk/docs/project/release_manager_guide.pod 35885 2009-01-21T08:08:42.597406Z chromatic  $

=head1 Release Instructions

To prepare a release:

=over 4

=item 0.

As soon as you become the release manager: review the goals for the release on
the Parrot roadmap (L<https://trac.parrot.org/parrot/wiki/ParrotRoadmap>) and
announce the tasks to the Parrot mailing list.  Make sure everyone knows what
they've committed to accomplish in time for the release.  Ask the previous
release manager to review PAUSE permissions so that PARROTRE owns all files.

A couple of weeks in advance: Ask people to run C<make fulltest> and report
(and hopefully fix!) any problems they find.

A couple of days in advance: announce the new release to
parrot-dev@lists.parrot.org and to the IRC channel #parrot.  Ask whether there
are any showstopping bugs.  It's also good to ask for updates to F<NEWS>,
F<CREDITS>, F<PLATFORMS>, F<RESPONSIBLE_PARTIES> and L<https://trac.parrot.org/parrot/wiki/Languages>.

You might also select a name for your release. For example, you could
select a name from L<http://en.wikipedia.org/wiki/List_of_parrots>.

Set up your account on L<http://www.parrot.org/> and ask one of Allison, Jerry,
Jeff, Will, or chromatic to bestow you story-creating powers.

=item 1.

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,
make release-related changes there, and fold them back into the trunk
once the release is done. This process is explained in
L<Appendix 1|"Appendix 1 - Releasing from a branch">.

=item 2.

Update files with version-specific information:

=over 4

=item a

Increment the version number in the following files:
F<VERSION>, F<parrot.spec>, F<MANIFEST.generated>, F<META.yml>,
F<README>.

Note: C<Source0> in parrot.spec might have to be adapted as well.

Also update the version number, date, and your name in the
the file: F<docs/parrothist.pod>.

Update this file, that is F<release_manager_guide.pod>,
to remove the pending release you're in the middle of.

=item b

Update F<ChangeLog>, F<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. If not, it's probably a good idea
to gather the updates weekly rather than waiting until the day of the
monthly release.

=item c

Update release-related information in F<tools/util/release.json>. This will 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 2|"Appendix 2 - Upcoming releases">.

=item C<bugday.date>

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.

=back

=item d

Make sure F<RESPONSIBLE_PARTIES> is still accurate.

=item e

Give yourself credit for the release in F<CREDITS>.

=item f

Configure parrot and run C<make distro_tests>, and either fix
what those tests complain about, or fix them so they don't complain.

=item g

Run C<perl tools/dev/pbc_header.pl --upd t/native_pbc/*.pbc>
to update version and fingerprint in the native tests.
Please check with C<prove t/native_pbc/*.t>.

NOTE: Due to frequent PBC changes, these tests are currently skipped.

=item h

Make sure everything works:

 $ make realclean
 $ perl Configure.pl --test ...
 $ make world docs html 2>&1 | tee make_world_docs_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.

=back

=item 3.

When all is well, then commit your changes:

 svn diff | more
 svn commit

Write down the revision number from this commit. You will need it later in
step 7.

=item 4.

Prepare the release tarball.

 $ make release VERSION=a.b.c

where a.b.c is the version number. This will create the tarball named
F<parrot-a.b.c.tar.gz>. This will automatically avoid including C<DEVELOPING>
in the release tarball.

=item 5.

Untar F<parrot-a.b.c.tar.gz> into another area.

=item 6.

Make sure everything works:

 $ perl Configure.pl
 $ make world docs html 2>&1 | tee make_world_docs_html.log
 $ make fulltest        2>&1 | tee make_fulltest.log

=item 7.

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" \
   $SVNPARROT/trunk $SVNPARROT/tags/RELEASE_a_b_c

See also L<Appendix 1|"Appendix 1 - Releasing from a branch"> below.

=item 8.

=over 4

=item a. CPAN

In PAUSE, assign yourself co-maintainer permissions on all modules owned by
PARROTRE.

Upload to CPAN.

NOTE: you may get a failure message from the CPAN Indexer about the content of
META.yml. Don't panic, the tarball still uploaded okay.  You do need to fix
META.yml for the next release. Under "no_index" list any modules that aren't
properly part of the Parrot distribution.

Once you get a reply from the PAUSE indexer, log in to PAUSE to clean up module
permissions. Under "View Permissions" search for your PAUSE ID. Any new modules
added in this release will list your PAUSE ID as the "owner". Change the owner
to PARROTRE.

See F<docs/project/pause_guide.pod> for more details.

=item b. FTP

SSH to ftp-osl.osuosl.org. (If you don't have the necessary login information,
get it from one of the previous release managers.)

 $ ssh -l <USERNAME> ftp-osl.osuosl.org

If the release is a monthly development release, create a new directory under
F<~/ftp/releases/devel>.

 $ mkdir ~/ftp/releases/devel/a.b.c

If the release is in the stable series (1.0, 1.5, 2.0, 2.5, etc) create
the new directory in F<~/ftp/releases/stable> instead.

 $ mkdir ~/ftp/releases/stable/a.b.c

Copy the tarball from your machine into the new directory.

 $ scp parrot-a.b.c.tar.gz ftp-osl.osuosl.org:~/ftp/releases/devel/a.b.c/.

(Or using C<wget> or whatever tool you prefer.)

When you're finished making changes, run the trigger script to push the changes
out to the FTP mirrors.

  ~/trigger-parrot

Check your changes at F<ftp://ftp.parrot.org/pub/parrot/releases>. It should
only take a few minutes for the mirrors to sync.

=back

=item 9.

Compose the release announcement.  Use F<tools/util/crow.pir> to make
this part easier.  You can specify the format of your announcements 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.  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.

=item 10.

Update the website. You will need an account on L<http://www.parrot.org>.

=over 4

=item a

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
old announcements as a guide.

The "<!--break-->" line marks the end of the text that will appear on the
front page.

=item b

Set the "News" category to "Releases".

Add tags to the page for significant changes in this release (e.g. "rakudo" for
significant Rakudo language updates, or "gc" for significant garbage collection
subsystem updates).

=item c

Under "URL path settings" uncheck "Automatic alias" and set the path to
news/[year]/Parrot-[release number].

=item d

Under "Publishing options" make sure "Published" and "Promoted to front page"
are checked.

=item e

Under "Administer" -> "Site building" -> "URL Redirects", change the URL for
"release/current" to the FTP directory for the new release (for example,
F<ftp://ftp.parrot.org/pub/parrot/releases/devel/0.8.1>).

=back

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

=item 11.

Publicize the release by publishing the announcement through the
following channels (and any others you can think of):

=over 4

=item a

Send a text email to parrot-dev, perl6-language, perl6-announce,
perl5-porters, etc.  You should also include LWN.net in this mailing; email to
C<lwn> at that domain.

=item b

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.

=item c

Modify the topic on #parrot, e.g.:

 /topic #parrot Parrot 0.4.8 Released | http://parrot.org/

=item d

Update the wiki frontpage at L<http://www.perlfoundation.org/parrot/index.cgi?parrot>.
Update the next planned release date on the wiki at L<http://www.perlfoundation.org/parrot/index.cgi?release_schedule_2008>.

=item e

Update the Wikipedia entry at L<http://en.wikipedia.org/wiki/Parrot_virtual_machine>.

=item f

Update the C2 wiki entry at L<http://c2.com/cgi/wiki?ParrotCode>.

=back

=item 12.

Close any release-related tickets in trac. Migrate any critical tickets
to the next milestone; non-critical tickets can have their milestone unset.

=item 13.

Add the version to trac so new bug reports can be filed against your
buggy code. L<https://trac.parrot.org/parrot/admin/ticket/versions>

Remove any sufficiently old versions listed there.

=item 14.

You're done! Help yourself to a beer, cola, or other celebratory drink.

=back

=head2 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 - Releasing from a branch

Instead of step 1, create a new branch, and get a working copy of it:

   $ export SVNPARROT=https://svn.perl.org/parrot
   $ svn copy -m"Starting release a.b.c" \
              $SVNPARROT/trunk $SVNPARROT/branches/RELEASE_a_b_c
   $ svn checkout $SVNPARROT/branches/RELEASE_a_b_c parrot-release
   $ cd parrot-release

Make a note of the revision number produced by C<svn copy> so that you
know which changes were made on the branch.

This new C<parrot-release> working copy will be "on" the branch,
insulated from trunk commits, so you should feel free to announce the
end of any "code slush" that may be in effect.

Then, do steps 3 through 7 using your branch working copy, so that
commits go to the branch.  When you are sure that the tarball is all
that it should be, tag the release as a copy from the branch (instead
of the trunk):

   $ svn copy -m"Release a.b.c" \
           $SVNPARROT/branches/RELEASE_a_b_c $SVNPARROT/tags/RELEASE_a_b_c

Alternatively you can also move the branch:

   $ svn move -m "Tagging release a.b.c" \
           $SVNPARROT/branches/RELEASE_a_b_c $SVNPARROT/tags/RELEASE_a_b_c

Upload your shiny new tarball, announce the release, and close tickets
(steps 9 through 11) as described above.

Finally (don't get your celebratory drink yet!), you need to merge the
branch changes back into the trunk.  To do this, you need an
up-to-date working copy on the trunk.  You can reuse the
C<parrot-release> working copy via C<svn switch> by switching it back
to the trunk (assuming C<parrot-release> is the current directory):

   $ svn switch $SVNPARROT/trunk

Then, merge the branch changes back into it:

   $ svn merge -r 12345:HEAD $SVNPARROT/branches/RELEASE_a_b_c

where "12345" is the revision number of the C<svn copy> operation that
created the branch.  Check that the merge was clean, "make test" if
there were any code changes on the branch, and commit.  I<Then> go get
that beer!

=head1 Appendix 2 - Upcoming releases

To make a monthly release schedule possible, we're spreading the burden
of releases across multiple release managers.  Releases are scheduled for
the 3rd Tuesday of each month. Version numbers for each release will be
determined each month, and will depend on the features actually present in
that release.

 - February 17, 2009 - 0.9.1
 - March 17, 2009  - 1.0.0

=cut

__END__
Local Variables:
  fill-column:78
End:
