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
-
-This produces a file containing a list of suggested edits, e.g.:
-
- 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.
+ $ ./perl -Ilib Porting/bump-perl-version -i 5.10.0 5.10.1
-Instead of these two steps, bump-perl-version can also make these changes
-inplace in one step, and you can use git status and git diff to select
-changes you want to keep:
+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"!
- $ ./perl -Ilib Porting/bump-perl-version -i 5.10.0 5.10.1
+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
The line in F<INSTALL> about "is binary incompatible with" requires a
correct choice of earlier version to declare incompatibility with.
-Also note that this tool
-currently only detects a single substitution per line: so in particular,
-this line in README.vms needs special handling:
-
- rename perl-5^.10^.1.dir perl-5_10_1.dir
-
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
Commit your changes:
- $ git st
+ $ git status
$ git diff
B<review the delta carefully>
=head3 finalize perldelta
Finalize the perldelta. In particular, fill in the Acknowledgements
-section. You can generate a list of contributors with checkAUTHORS.pl.
-For example:
+section, which can be generated with something like:
- $ git log --pretty=fuller v5.13.${last}..HEAD | \
- perl Porting/checkAUTHORS.pl --who -
-
-Look at the previous L<perldelta> for how to write the opening
-paragraph of the Acknowledgements section. To get the amount of
-changed files and number of lines use this command:
-
- $ git diff --shortstat v5.13.${last}..HEAD | \
- ./perl -Ilib -nE 'my ($files, $insert, $delete) = /(\d+)/ga; say "$files files and ", $insert + $delete, " lines changed"'
-
-Making sure to round off the number of lines changed.
+ $ perl Porting/acknowledgements.pl v5.15.0..HEAD
Re-read the perldelta to try to find any embarrassing typos and thinkos;
remove any C<TODO> or C<XXX> flags; update the "Known Problems" section
If necessary, bump C<$VERSION> (there's no need to do this for
every RC; in RC1, bump the version to a new clean number that will
appear in the final release, and leave as-is for the later RCs and final).
+It may also happen that C<Module::CoreList> has been modified in blead, and
+hence has a new version number already. (But make sure it is not the same
+number as a CPAN release.)
Edit the version number in the new C<< 'Module::CoreList' => 'X.YZ' >>
entry, as that is likely to reflect the previous version number.
Add a perldelta entry for the new Module::CoreList version.
-You should also add the version you're about to release to the
-L<Module::CoreList/CAVEATS> section which enumerates the perl releases
-that Module::CoreList covers.
-
In addition, if this is a final release (rather than a release candidate):
=over 4
=head3 build the tarball
+Before you run the following, you might want to install 7-Zip (the
+C<p7zip-full> package under Debian or the C<p7zip> port on MacPorts) or
+the AdvanceCOMP suite (e.g. the C<advancecomp> package under Debian,
+or the C<advancecomp> port on macports - 7-Zip on Windows is the
+same code as AdvanceCOMP, so Windows users get the smallest files
+first time). These compress about 5% smaller than gzip and bzip2.
+Over the lifetime of your distribution this will save a lot of
+people a small amount of download time and disk space, which adds
+up.
+
Create a tarball. Use the C<-s> option to specify a suitable suffix for
the tarball and directory name:
XXX if we go for extra tags and branches stuff, then add the extra details
here
-Optionally, you might want to compress your tarball more. Unix F<gzip>
-doesn't actually produce the smallest possible DEFLATE output. If you have the
-AdvanceCOMP suite (e.g. the C<advancecomp> port on macports), you can run
-
- $ advdef -z -4 ../perl-x.y.z-RC1.tar.gz
-
-which will probably shrink your tarball by about 5%. Over the lifetime of
-your distribution this will save a lot of people a small amount of download
-time and disk space, which adds up.
-
-(7-Zip on Windows is the same code as AdvanceCOMP, so Windows users get the
-smallest files first time)
-
-
Finally, clean up the temporary directory, e.g.
$ rm -rf ../perl-x.y.z-RC1