From 04dbb930790f65897bff3bb82bb961f95014aa10 Mon Sep 17 00:00:00 2001 From: David Golden Date: Fri, 30 Jul 2010 22:00:10 +0000 Subject: [PATCH] Update release managers guide with notes from 5.13.3 release --- Porting/release_managers_guide.pod | 31 +++++++++++++++++++++++++------ 1 file changed, 25 insertions(+), 6 deletions(-) diff --git a/Porting/release_managers_guide.pod b/Porting/release_managers_guide.pod index 088df03..2351197 100644 --- a/Porting/release_managers_guide.pod +++ b/Porting/release_managers_guide.pod @@ -175,7 +175,8 @@ run the following: to see any inconsistencies between the core and CPAN versions of distros, then fix the core, or cajole CPAN authors as appropriate. See also the C<-d> and C<-v> options for more detail. You'll probably want to use the -C<-c cachedir> option to avoid repeated CPAN downloads. +C<-c cachedir> option to avoid repeated CPAN downloads and may want to +use C<-m file:///mirror/path> if you made a local CPAN mirror. To see which core distro versions differ from the current CPAN versions: @@ -241,6 +242,10 @@ changed since the previous release, but which still have the old version number. If there is more than one maintenance branch (e.g. 5.8.x, 5.10.x), then compare against both. +Be sure to bump the version numbers in separate commits for each module +(or group of related modules) so that changes can be cherry-picked later +if necessary. + Note that some of the files listed may be generated (e.g. copied from ext/ to lib/, or a script like lib/lib_pm.PL is run to produce lib/lib.pm); make sure you edit the correct file! @@ -266,11 +271,14 @@ edit the whole document. I -A week or two before the first release candidate, bump the perl version -number (e.g. from 5.10.0 to 5.10.1), 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 bump the version further. +Bump the version number (e.g. from 5.12.0 to 5.12.1). + +For a blead 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 +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 +bump the version further. There is a tool to semi-automate this process. It works in two stages. First, it generates a list of suggested changes, which you review and @@ -306,6 +314,9 @@ this line in README.vms needs special handling: rename perl-5^.10^.1.dir perl-5_10_1.dir +Also be careful of F, which has legacy version +numbers that should not get changed. + Commit your changes: $ git st @@ -385,8 +396,16 @@ up-to-date. =item * +For a blead release, if you did not bump the perl version number as part +of I, do that now. + +=item * + I +Finalize the perldelta. In particular, fill in the Acknowledgements +section. + Re-read the perldelta to try to find any embarrassing typos and thinkos; remove any C or C flags; update the "Known Problems" section with any serious issues for which fixes are not going to happen now; and -- 2.7.4