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
-edit; then you feed this list back and it applies the edits. So, first
-scan the source directory looking for likely candidates. The command line
-arguments are the old and new version numbers, and -s means scan:
+There is a tool to semi-automate this process:
- $ ./perl -Ilib Porting/bump-perl-version -s 5.10.0 5.10.1 > /tmp/scan
+ $ ./perl -Ilib Porting/bump-perl-version -i 5.10.0 5.10.1
-This produces a file containing a list of suggested edits, e.g.:
+Remember that this tool is largely just grepping for '5.10.0' or whatever,
+so it will generate false positives. Be careful not change text like
+"this was fixed in 5.10.0"!
- NetWare/Makefile
-
- 89: -MODULE_DESC = "Perl 5.10.0 for NetWare"
- +MODULE_DESC = "Perl 5.10.1 for NetWare"
-
-i.e. in the file F<NetWare/Makefile>, line 89 would be changed as shown.
-Review the file carefully, and delete any -/+ line pairs that you don't
-want changing. You can also edit just the C<+> line to change the
-suggested replacement text. Remember that this tool is largely just
-grepping for '5.10.0' or whatever, so it will generate false positives. Be
-careful not change text like "this was fixed in 5.10.0"! Then run:
-
- $ ./perl -Ilib Porting/bump-perl-version -u < /tmp/scan
-
-which will update all the files shown.
+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
$ 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 8891dd8d 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 BLEAD-POINT releases, it needs to refer to the previous BLEAD-POINT
release (so for 5.15.3 this would be 5.15.2).
-
-=head3 update Changes
-
-Update the F<Changes> file to contain the git log command which would show
-all the changes in this release. You will need assume the existence of a
-not-yet created tag for the forthcoming release; e.g.
-
- git log ... perl-5.10.0..perl-5.12.0
-
-Due to warts in the perforce-to-git migration, some branches require extra
-exclusions to avoid other branches being pulled in. Make sure you have the
-correct incantation: replace the not-yet-created tag with C<HEAD> and see
-if C<git log> produces roughly the right number of commits across roughly the
-right time period (you may find C<git log --pretty=oneline | wc> useful).
-
-
=head3 Check more build configurations
Check some more build configurations. The check that setuid builds and
=head3 update perlhist.pod
-Add an entry to F<pod/perlhist.pod> with the current date, e.g.:
+I<You MUST SKIP this step for a RC release>
- David 5.10.1-RC1 2009-Aug-06
+Add an entry to F<pod/perlhist.pod> with the release date, e.g.:
+
+ David 5.10.1 2009-Aug-06
Make sure that the correct pumpking is listed in the left-hand column, and
if this is the first release under the stewardship of a new pumpking, make
Now you need to update various tables of contents related to perldelta,
most of which can be generated automatically.
-Edit F<pod.lst>: add the new entry, flagged as 'd', and unflag the previous
-entry from being 'd'; for example:
-
- -d perl5101delta Perl changes in version 5.10.1
- +d perl5102delta Perl changes in version 5.10.2
- + perl5101delta Perl changes in version 5.10.1
+Edit F<pod.lst>: add the new entry for the perlNNNdelta file for the
+current version (the file that will be symlinked to perldelta).
Manually create a temporary link to the new delta file; normally this is
done from the Makefile, but the Makefile is updated by buildtoc, and
$ git commit -a -m 'update TOC for perlNNNdelta'
-At this point you may want to compare the commit with a previous bump to
-see if they look similar. See commit 8891dd8d for an example of a
+At this point you may want to compare the commit with a previous bump to
+see if they look similar. See commit dd885b5 for an example of a
previous version bump.
=head3 update perlhist.pod in other branches
Make sure any recent F<pod/perlhist.pod> entries are copied to
-F<perlhist.pod> on other branches; typically the RC* and final entries,
+F<perlhist.pod> on other branches
e.g.
- 5.8.9-RC1 2008-Nov-10
- 5.8.9-RC2 2008-Dec-06
5.8.9 2008-Dec-14
=head3 bump RT version number
-If necessary, send an email to C<perlbug-admin at perl.org> requesting
-that new version numbers be added to the RT fields C<Perl Version> and
-C<Fixed In>.
-
+Log into http://rt.perl.org/ and check whether the new version is
+in the RT fields C<Perl Version> and C<Fixed In>. If not, send an
+email to C<perlbug-admin at perl.org> requesting this.
=head3 Relax!
I<This step ONLY for BLEAD-POINT and MAINT>
-Ask Rafael to update L<http://dev.perl.org/perl5/>.
+Ask Leo Lapworth to update L<http://dev.perl.org/perl5/>.
=head1 SOURCE
https://perl5.git.perl.org / perl5.git / blobdiff