Several improvements to the RMG

Porting/make-rmg-checklist

@@ -155,6 +155,7 @@ my $passthru_headers = qr/^= (?: over | item | back | cut )/xms;
 my ($major, $minor, $point_with_maybe_rc) = split(/\./, $version);
 my ($point) = split(/-/, $point_with_maybe_rc);
 my $last_version = join('.', $major, ($point == 0 ? ($minor - 2, 0) : ($minor, $point-1)));
+my $next_version = join('.', $major, ($point == 0 && $minor % 2 == 0 ? ($minor + 1, 0) : ($minor, $point+1)));
 
 # Oldest version ("previous stable") that still has full support.
 # This is supposed to match the "Version Support Status" table in perlpolicy.pod
@@ -196,6 +197,7 @@ foreach my $line (@pod_lines) {
 
     $line =~ s/\Q5.X.Y\E/$version/g;
     $line =~ s/\Q5.LAST\E/$last_version/g;
+    $line =~ s/\Q5.NEXT\E/$next_version/g;
     $line =~ s/\Q5.X\E\b/$major.$minor/g;
     $line =~ s/\Q5.OLDSUPPORT\E/$old_support/g;
 

Porting/release_managers_guide.pod

@@ -48,6 +48,19 @@ last component is 0, it subtracts 2 from the middle component:
     5.40.0  ->  5.38.0
     5.41.0  ->  5.39.0
 
+=item C<5.NEXT>
+
+The "next" perl version. Normally, this is just C<5.X.(Y+1)>, but if the
+last component is 0, and the middle component is even, it adds 1 to the
+middle component:
+
+    5.X.Y       5.NEXT
+    ======      ======
+    5.41.9  ->  5.41.10
+    5.40.1  ->  5.40.2
+    5.40.0  ->  5.41.0
+    5.41.0  ->  5.41.1
+
 =item C<5.OLDSUPPORT>
 
 The oldest release series that is officially eligible for support, as per
@@ -550,7 +563,9 @@ described below in L</"Update Module::CoreList">).
 
 =head3 Bump the version number
 
-Increase the version number (e.g. from 5.12.0 to 5.12.1).
+(Note: the example version numbers are incorrect for a MAINT release.)
+
+Increase the version number (e.g. from 5.41.13 to 5.42.0).
 
 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
@@ -560,48 +575,27 @@ bump the version further.
 
 There is a tool to semi-automate this process:
 
- $ ./perl -Ilib Porting/bump-perl-version -i 5.10.0 5.10.1
+ $ ./perl -Ilib Porting/bump-perl-version -i 5.41.13 5.42.0
 
-Remember that this tool is largely just grepping for '5.10.0' or whatever,
+Remember that this tool is largely just grepping for '5.41.13' or whatever,
 so it will generate false positives. Be careful not change text like
-"this was fixed in 5.10.0"!
+"this was fixed in 5.41.13"!
 
 Use git status and git diff to select changes you want to keep.
 
 Be particularly careful with F<INSTALL>, which contains a mixture of
-C<5.10.0>-type strings, some of which need bumping on every release, and
+C<5.41.13>-type strings, some of which need bumping on every release, and
 some of which need to be left unchanged.
 See below in L</"Update INSTALL"> for more details.
 
-For the first RC release leading up to a BLEAD-FINAL release, update
-F<pod/perlpolicy.pod>: both the version support status table and the
-description of which releases are now "officially" supported.
-
-That description should match up with these following notes, used to
-fill the C<END OF SUPPORT NOTE> placeholder when preparing the
-release announcement email.
-
-For a BLEAD-FINAL RC release:
-
-    Support for the 5.OLDSUPPORT.x release series will end shortly.
-    Please refer to L<perlpolicy> for version support information.
-
-For a BLEAD-FINAL release:
-
-    Support for the 5.OLDSUPPORT.x release series has now ended.
-    Please refer to L<perlpolicy> for version support information.
-
-MAINT release announcements must not contain C<END OF SUPPORT NOTE> text.
-
-When doing a BLEAD-POINT or BLEAD-FINAL release, also make sure the
-C<PERL_API_*> constants in F<patchlevel.h> are in sync with the version
-you're releasing, unless you're absolutely sure the release you're about to
-make is 100% binary compatible to an earlier release. Note: for BLEAD-POINT
-releases the bump should have already occurred at the end of the previous
-release and this is something you would have to do at the very end.
 When releasing a MAINT perl version, the C<PERL_API_*> constants C<MUST NOT>
 be changed as we aim to guarantee binary compatibility in maint branches.
 
+When doing a BLEAD-FINAL release, make sure the C<PERL_API_*> constants
+in F<patchlevel.h> are in sync with the version you're releasing,
+unless you're absolutely sure the release you're about to make is 100%
+binary compatible to an earlier release.
+
 After editing, you may need to regen opcodes:
 
  $ ./perl -Ilib regen/opcode.pl
@@ -624,30 +618,22 @@ Commit your changes:
 
  $ git commit -a -m 'Bump the perl version in various places for 5.X.Y'
 
-At this point you may want to compare the commit with a previous bump to
-see if they look similar.  See commit L<f7cf42bb69|https://github.com/Perl/perl5/commit/f7cf42bb69> for an example of a
-previous version bump.
+At this point you may want to compare the commit with
+a previous bump to see if they look similar.  See commit
+L<f7cf42bb69|https://github.com/Perl/perl5/commit/f7cf42bb69> for an
+example of a previous version bump.
 
 When the version number is bumped, you should also update Module::CoreList
 (as described below in L</"Update Module::CoreList">) to reflect the new
 version number.
 
-=for checklist skip RC BLEAD-FINAL MAINT
-=head3 Prepare an end of support note (if necessary)
-
-For the I<final> BLEAD-POINT release in a development cycle, the
-release announcement email should note the upcoming end of support
-for the oldest of the currently supported release series.
-
-Replace the C<END OF SUPPORT NOTE> placeholder with this text:
-
-    Support for the 5.OLDSUPPORT.x release series will end shortly.
-    Please refer to L<perlpolicy> for version support information.
+=for checklist skip BLEAD-POINT
 
-Check L<perlpolicy> to confirm the affected VERSION before sending!
+=head3 Update the "Version Support Status" section in perlpolicy
 
-For all other BLEAD-POINT releases, there is no need for an
-C<END OF SUPPORT NOTE>.
+For the first RC release leading up to a BLEAD-FINAL release, update
+F<pod/perlpolicy.pod>: both the version support status table and the
+description of which releases are now "officially" supported.
 
 =head3 Update INSTALL
 
@@ -1432,9 +1418,50 @@ Be sure to commit your change:
 =head3 Announce to p5p
 
 Mail perl5-porters@perl.org to announce your new release, with a quote you prepared earlier.
+
+=head4 Prepare the announcement email
+
 Get the SHA256 digests from the PAUSE email responses.
 
-Use the template at Porting/release_announcement_template.txt
+Use the template at F<Porting/release_announcement_template.txt>.
+
+=for checklist skip RC BLEAD-FINAL MAINT
+
+=head4 Add an end of support note (if necessary)
+
+For the I<final> BLEAD-POINT release in a development cycle, the
+release announcement email should note the upcoming end of support
+for the oldest of the currently supported release series.
+
+Replace the C<END OF SUPPORT NOTE> placeholder with this text:
+
+    Support for the 5.OLDSUPPORT.x release series will end shortly.
+    Please refer to L<perlpolicy> for version support information.
+
+Check F<pod/perlpolicy.pod> to confirm the affected VERSION before sending!
+
+For all other BLEAD-POINT releases, there is no need for an
+C<END OF SUPPORT NOTE>.
+
+=for checklist skip BLEAD-POINT MAINT
+
+=head4 Add an end of support note
+
+For the BLEAD-FINAL (and corresponding RC) release in a development cycle,
+the release announcement email should note the end of support
+for the oldest of the currently supported release series.
+
+For a BLEAD-FINAL RC release:
+
+    Support for the 5.OLDSUPPORT.x release series will end shortly.
+    Please refer to L<perlpolicy> for version support information.
+
+For a BLEAD-FINAL release:
+
+    Support for the 5.OLDSUPPORT.x release series has now ended.
+    Please refer to L<perlpolicy> for version support information.
+
+=head4 Finalize and send the email
 
 Send a carbon copy to C<noc@metacpan.org>
 
@@ -1590,24 +1617,74 @@ reports to arise. (The opposite problem -- trying to figure out why there
 introduced later -- shouldn't arise for MAINT releases since they should,
 in theory, only contain bug fixes but never regressions.))
 
-=for checklist skip RC MAINT
+=for checklist skip RC MAINT BLEAD-FINAL
 
-=head3 Bump the version number
+=head3 Bump the point version number
+
+Increase the minor version number (e.g. from 5.X.Y to 5.NEXT).
+
+There is a tool to semi-automate this process:
+
+ $ ./perl -Ilib Porting/bump-perl-version -i 5.X.Y 5.NEXT
+
+Remember that this tool is largely just grepping for '5.X.Y' or whatever,
+so it will generate false positives. Be careful not change text like
+"this was fixed in 5.X.Y"!
+
+Use git status and git diff to select changes you want to keep.
+
+Be particularly careful with F<INSTALL>, which contains a mixture of
+C<5.X.Y>-type strings, some of which need bumping on every release, and
+some of which need to be left unchanged.
+See below in L</"Update INSTALL"> for more details.
+
+After editing, you may need to regen opcodes:
+
+ $ ./perl -Ilib regen/opcode.pl
+
+Test your changes:
+
+ $ git clean -xdf   # careful if you don't have local files to keep!
+ $ ./Configure -des -Dusedevel
+ $ make
+ $ make test_harness
+
+Do note that at this stage, porting tests will fail. They will continue
+to fail until you've updated Module::CoreList, as described below.
+
+Commit your changes:
+
+ $ git status
+ $ git diff
+ # Review the delta carefully
+ $ git commit -a -m 'Bump the perl version in various places for 5.X.Y'
+
+At this point you may want to compare the commit with a previous bump to
+see if they look similar.  See commit L<48b1717bed|https://github.com/Perl/perl5/commit/48b1717bed> for an example of a
+previous version bump.
+
+When the version number is bumped, you should also update Module::CoreList
+(as described in L</"Update Module::CoreList">) to reflect the new
+version number.
+
+=for checklist skip RC MAINT BLEAD-POINT
+
+=head3 Bump the version number for the new dev cycle
 
-Increase the version number (e.g. from 5.12.0 to 5.12.1).
+Increase the version number (e.g. from 5.X.Y to 5.NEXT).
 
 There is a tool to semi-automate this process:
 
- $ ./perl -Ilib Porting/bump-perl-version -i 5.10.0 5.10.1
+ $ ./perl -Ilib Porting/bump-perl-version -i 5.X.Y 5.NEXT
 
-Remember that this tool is largely just grepping for '5.10.0' or whatever,
+Remember that this tool is largely just grepping for '5.X.Y' or whatever,
 so it will generate false positives. Be careful not change text like
-"this was fixed in 5.10.0"!
+"this was fixed in 5.X.Y"!
 
 Use git status and git diff to select changes you want to keep.
 
 Be particularly careful with F<INSTALL>, which contains a mixture of
-C<5.10.0>-type strings, some of which need bumping on every release, and
+C<5.X.Y>-type strings, some of which need bumping on every release, and
 some of which need to be left unchanged.
 See below in L</"Update INSTALL"> for more details.