Add the new smoke report test site

[perl5.git] / Porting / release_managers_guide.pod

diff --git a/Porting/release_managers_guide.pod b/Porting/release_managers_guide.pod
index d442f84..7e6cb04 100644 (file)
--- a/Porting/release_managers_guide.pod
+++ b/Porting/release_managers_guide.pod
@@ -268,7 +268,7 @@ bit, or edit F<Porting/exec-bit.txt>
 
 =item *
 
-Run C<make>, see if C<perl> compiles.
+Run C<make> (or C<nmake> on Windows), see if C<perl> compiles.
 
 =item *
 
@@ -296,7 +296,10 @@ For entries with a non-simple C<FILES> section, or with a C<MAP>, you
 may have to take more steps than listed above.
 
 F<Porting/sync-with-cpan> is a script that automates most of the steps
-above; but see the comments at the beginning of the file.
+above; but see the comments at the beginning of the file.  In particular,
+it has not yet been exercised on Windows, but will certainly require a set
+of Unix tools such as Cygwin, and steps that run C<make> will need to run
+C<nmake> instead.
 
 
 =head3 dual-life CPAN module stability
@@ -325,7 +328,8 @@ Ensure dual-life CPAN modules are stable, which comes down to:
 =head3 monitor smoke tests for failures
 
 Similarly, monitor the smoking of core tests, and try to fix.  See
-L<http://doc.procura.nl/smoke/index.html> for a summary. See also
+L<http://doc.procura.nl/smoke/index.html> and L<http://perl5.test-smoke.org/>
+for a summary. See also
 L<http://www.nntp.perl.org/group/perl.daily-build.reports/> which has
 the raw reports.
 
@@ -344,10 +348,12 @@ edit the whole document.
 
 =head3 Bump the version number
 
+Do not do this yet for a BLEAD-POINT release! You will do this at the end of
+the release process.
+
 Increase the version number (e.g. from 5.12.0 to 5.12.1).
 
-For a BLEAD-POINT release, this can happen on the day of the release.  For a
-release candidate for a stable perl, this should happen a week or two
+For a release candidate for a stable perl, this should happen a week or two
 before the first release candidate to allow sufficient time for testing and
 smoking with the target version built into the perl executable. For
 subsequent release candidates and the final release, it it not necessary to
@@ -457,10 +463,14 @@ L<"Building a release - advance actions"> to ensure they are all done and
 up-to-date.
 
 
-=head3 bump version number
+=head3 create a release branch
+
+For BLEAD-POINT releases, making a release from a release branch avoids the
+need to freeze blead during the release. This is less important for
+BLEAD-FINAL, MAINT, and RC releases, since blead will already be frozen in
+those cases. Create the branch by running
 
-For a BLEAD-POINT release, if you did not bump the perl version number as
-part of I<advance actions>, do that now.
+  git checkout -b release-5.xx.yy
 
 
 =head3 finalize perldelta
@@ -579,10 +589,6 @@ Check that file over carefully:
 
     $ git diff dist/Module-CoreList/lib/Module/CoreList.pm
 
-If this is a .0 Perl version, add the appropriate lines in F<Corelist.pm>
-to alias "5.nnn000" to "5.nnn" in each hash.  (If feeling energetic,
-amend F<corelist.pl> to automate this.)
-
 =head4 Bump C<$Module::CoreList::VERSION>
 
 If necessary, bump C<$Module::CoreList::VERSION> (there's no need to do this for
@@ -820,17 +826,13 @@ previous is 5.10.0:
     find . -type f | sort > /tmp/f2
     diff -u /tmp/f[12]
 
-=head4 Test the CPAN client
+=head4 Bootstrap the CPAN client
 
 Bootstrap the CPAN client on the clean install:
 
-    $ bin/perl -MCPAN -e "shell"
+    $ bin/cpan
 
-If you're running this on Win32 you probably also need a set of Unix
-command-line tools available for CPAN to function correctly without
-Perl alternatives like LWP installed. Cygwin is an obvious choice.)
-
-=head4 Install the Inline module and test it
+=head4 Install the Inline module with CPAN and test it
 
 Try installing a popular CPAN module that's reasonably complex and that
 has dependencies; for example:
@@ -850,10 +852,6 @@ Bootstrap the CPANPLUS client on the clean install:
 
     $ bin/cpanp
 
-(Again, on Win32 you'll need something like Cygwin installed, but make sure
-that you don't end up with its various F<bin/cpan*> programs being found on
-the PATH before those of the Perl that you're trying to test.)
-
 =head4 Install the DBI module with CPANPLUS
 
     CPAN Terminal> i DBI
@@ -977,6 +975,18 @@ Use the template at Porting/release_announcement_template.txt
 
 Send a carbon copy to C<noc@metacpan.org>
 
+=head3 merge release branch back to blead
+
+If you made a release branch for this release, merge it back into master now,
+and delete it.
+
+  git checkout blead
+  git pull
+  git merge release-5.xx.yy
+  git push
+  git push origin :release-5.xx.yy
+  git branch -d release-5.xx.yy
+
 =head3 update epigraphs.pod
 
 Add your quote to F<Porting/epigraphs.pod> and commit it.
@@ -1042,11 +1052,11 @@ At this point you may want to compare the commit with a previous bump to
 see if they look similar.  See commit e3c71926d3 for an example of a
 previous version bump.
 
-=for checklist skip BLEAD-POINT MAINT RC
+=for checklist skip MAINT RC
 
 =head3 bump version
 
-I<You MUST SKIP this step for RC, BLEAD-POINT, MAINT>
+I<You MUST SKIP this step for RC and MAINT>
 
 If this was a BLEAD-FINAL release (i.e. the first release of a new maint
 series, 5.x.0 where x is even), then bump the version in the blead branch
@@ -1064,6 +1074,9 @@ Run F<regen/feature.pl> to propagate the changes to F<lib/feature.pm>.
 Then follow the section L<"Bump the version number"> to bump the version
 in the remaining files and test and commit.
 
+If this was a BLEAD-POINT release, then just follow the section
+L<"Bump the version number">.
+
 
 =head3 clean build and test
 
@@ -1148,7 +1161,7 @@ Edit F<pod/perl.pod> to add an entry for the file, e.g.:
 
 Then rebuild various files:
 
-    $ perl pod/buildtoc --build-all
+    $ perl Porting/pod_rules.pl
 
 Finally, commit: