You will need a working C<git> installation, checkout of the perl
git repository and perl commit bit. For information about working
-with perl and git, see F<pod/perlrepository.pod>.
+with perl and git, see F<pod/perlgit.pod>.
If you are not yet a perl committer, you won't be able to make a
release. Have a chat with whichever evil perl porter tried to talk
I<You MAY SKIP this step for SNAPSHOT>
-Similarly, monitor the smoking of core tests, and try to fix.
-See L<http://doc.procura.nl/smoke/index.html> for a summary.
+Similarly, monitor the smoking of core tests, and try to fix. See
+L<http://doc.procura.nl/smoke/index.html> for a summary. See also
+L<http://www.nntp.perl.org/group/perl.daily-build.reports/> which has
+the raw reports.
=item *
I<You MAY SKIP this step for SNAPSHOT>
-Run F<Porting/cmpVERSION.pl> to compare the current source tree with the
-previous version to check for for modules that have identical version
-numbers but different contents, e.g.:
-
- $ cd ~/some-perl-root
- $ ./perl -Ilib Porting/cmpVERSION.pl -xd . v5.10.0
-
-then bump the version numbers of any non-dual-life modules that have
-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!
-
-Once all version numbers have been bumped, re-run the checks.
-
-Then run again without the -x option, to check that dual-life modules are
-also sensible.
-
- $ ./perl -Ilib Porting/cmpVERSION.pl -d . v5.10.0
-
-=item *
-
-I<You MAY SKIP this step for SNAPSHOT>
-
Get perldelta in a mostly finished state.
Read F<Porting/how_to_write_a_perldelta.pod>, and try to make sure that
scan the source directory looking for likely candidates. The command line
arguments are the old and new version numbers, and -s means scan:
- $ Porting/bump-perl-version -s 5.10.0 5.10.1 > /tmp/scan
+ $ ./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.:
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:
- $ Porting/bump-perl-version -u < /tmp/scan
+ $ ./perl -Ilib Porting/bump-perl-version -u < /tmp/scan
which will update all the files shown.
$ git log --pretty=fuller v5.13.2..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.8..v5.13.9 | \
+ ./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.
+
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
with any serious issues for which fixes are not going to happen now; and
Also, you may want to generate and view an HTML version of it to check
formatting, e.g.
- $ perl pod/pod2html pod/perldelta.pod > /tmp/perldelta.html
+ $ ./perl -Ilib ext/Pod-Html/pod2html pod/perldelta.pod > /tmp/perldelta.html
Another good HTML preview option is http://search.cpan.org/pod2html
Make sure you have a gitwise-clean perl directory (no modified files,
unpushed commits etc):
- $ git clean -dxf
$ git status
+ $ git clean -dxf
=item *
=item *
-Check that files managed by F<regen.pl> and friends are up to date. From
-within your working directory:
-
- $ git status
- $ make regen_all
- $ make regen_perly
- $ git status
-
-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 regen; make regen_perly'
-
-(XXX regen might be a problem depending on the bison version available.
-We need to get a wizard to give better instructions on what to do or not do.)
-
-=item *
-
I<You MUST SKIP this step for SNAPSHOT>
Update C<Module::CoreList> with module version data for the new release.
Edit the version number in the new C<< 'Module::CoreList' => 'X.YZ' >>
entry, as that is likely to reflect the previous version number.
-Also edit Module::CoreList's new version number in its F<Changes> file and
-in its F<META.yml> file.
+Also edit Module::CoreList's new version number in its F<Changes>
+file.
+
+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):
Check that the manifest is sorted and correct:
- $ make manisort
$ make distclean
$ git clean -xdf # This shouldn't be necessary if distclean is correct
$ perl Porting/manicheck
- $ git status
-
- XXX manifest _sorting_ is now checked with make test_porting
-Commit MANIFEST if it has changed:
+If manicheck turns up anything wrong, update MANIFEST and begin this step again.
+ $ ./configure -des -Dusedevel
+ $ make test_porting
$ git commit -m 'Update MANIFEST' MANIFEST
=item *
Run the Installation Verification Procedure utility:
- $ bin/perlivp
+ $ ./perl utils/perlivp
...
All tests successful.
$
Bootstrap the CPAN client on the clean install:
- $ bin/perl -MCPAN -e'shell'
+ $ bin/perl -MCPAN -e "shell"
-(Use C<... -e "shell"> instead on Win32. You probably also need a set of
-Unix command-line tools available for CPAN to function correctly without
+If you're running this on Win32 you probably also need a set of Unix
+command-line tools available for CPAN to function correctly without
Perl alternatives like LWP installed. Cygwin is an obvious choice.)
=item *
Check that your perl can run this:
- $ bin/perl -lwe 'use Inline C => "int f() { return 42;} "; print f'
+ $ bin/perl -lwe "use Inline C => q[int f() { return 42;}]; print f"
42
$
-(Use C<... -lwe "use ..."> instead on Win32.)
-
=item *
Bootstrap the CPANPLUS client on the clean install:
Then check that the smoke tests pass (particularly on Win32). If not, go
back and fix things.
+Note that for I<BLEAD> releases this may not be practical. It takes a
+long time for the smokers to catch up, especially the Win32
+smokers. This is why we have a RC cycle for I<MAINT> releases, but for
+I<BLEAD> releases sometimes the best you can do is to plead with
+people on IRC to test stuff on their platforms, fire away, and then
+hope for the best.
=item *
=item *
+I<You MUST SKIP this step for SNAPSHOT or BLEAD release>
+
Disarm the F<patchlevel.h> change; for example,
static const char * const local_patches[] = {
win32/makefile.mk
win32/pod.mak
-Then manually edit (F<vms/descrip_mms.template> to bump the version
-in the following entry:
-
- [.pod]perl5101delta.pod : [.pod]perldelta.pod
-
-XXX this previous step needs to fixed to automate it in pod/buildtoc.
-
Finally, commit:
$ git commit -a -m 'update TOC for perlNNNdelta'
https://perl5.git.perl.org / perl5.git / blobdiff