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..perl5.12.0
+ 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
If any of the files managed by F<regen.pl> have changed, then you should
re-make perl to check that it's okay, then commit the updated versions:
- $ git commit -a -m 'make regn; make regn_perly'
+ $ git commit -a -m 'make regen; make regen_perly'
=item *
$ make perl
If this not the first update for this version, first edit
-F<lib/Module/CoreList.pm>to delete the existing entries for this version
-from the C<%released> and C<%version> hashes: they will have a key like
-C<5.010001> for 5.10.1.
+F<ext/Module-CoreList/lib/Module/CoreList.pm> to delete the existing
+entries for this version from the C<%released> and C<%version> hashes:
+they will have a key like C<5.010001> for 5.10.1.
XXX the edit-in-place functionality of Porting/corelist.pl should
be fixed to handle this automatically.
This will chug for a while, possibly reporting various warnings about
badly-indexed CPABN modules unreltaed to the modules actually in core.
-Assuming all goes well, it will update F<lib/Module/CoreList.pm>.
+Assuming all goes well, it will update
+F<ext/Module-CoreList/lib/Module/CoreList.pm>.
Check that file over carefully:
- $ git diff lib/Module/CoreList.pm
+ $ git diff ext/Module-CoreList/lib/Module/CoreList.pm
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
(unless this is for maint; in which case commit it blead first, then
cherry-pick it back).
- $ git commit -m 'Update Module::CoreList for 5.x.y' lib/Module/CoreList.pm
+ $ git commit -m 'Update Module::CoreList for 5.x.y' dist/Module-CoreList/lib/Module/CoreList.pm
=item *