perl-5.10.2 is released
post-release actions are performed, including creating new
- perl5103delta.pod
+ perldelta.pod
... the cycle continues ...
Check that your account is allowed to upload perl distros: goto
L<https://pause.perl.org/>, login, then select 'upload file to CPAN'; there
should be a "For pumpkings only: Send a CC" tickbox. If not, ask Andreas
-Kรถnig to add your ID to the list of people allowed to upload something
+KE<0xf6>nig to add your ID to the list of people allowed to upload something
called perl. You can find Andreas' email address at:
https://pause.perl.org/pause/query?ACTION=pause_04imprint
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.
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
-some of which need to be left unchanged. Also note that this tool
+some of which need to be left unchanged.
+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 release, also make sure the C<PERL_API_*> constants in
-F<patchlevel.h> are in sync with the with the version you're releasing, unless
-you're absolutely sure the release you're about to make is 100% binary
-compatible to an earlier release. When releasing a stable perl version, the
-C<PERL_API_*> constants C<MUST NOT> be changed as we aim to guarantee binary
-compatibility in maint branches.
+F<patchlevel.h> are in sync with the version you're releasing, unless you're
+absolutely sure the release you're about to make is 100% binary compatible
+to an earlier release. When releasing a stable perl version, the C<PERL_API_*>
+constants C<MUST NOT> be changed as we aim to guarantee binary compatibility
+in maint branches.
Commit your changes:
$ 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
run through pod and spell checkers, e.g.
- $ podchecker -warnings -warnings pod/perl5101delta.pod
- $ spell pod/perl5101delta.pod
+ $ podchecker -warnings -warnings pod/perldelta.pod
+ $ spell pod/perldelta.pod
Also, you may want to generate and view an HTML version of it to check
formatting, e.g.
- $ perl pod/pod2html pod/perl5101delta.pod > /tmp/perl5101delta.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:
=item *
-Check that the
C<perlbug> utility works. Try the following:
+Check that the
L<perlbug> utility works. Try the following:
$ bin/perlbug
...
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 *
Wait until you receive notification emails from the PAUSE indexer
confirming that your uploads have been received. IMPORTANT -- you will
-probably get an email that indexing has failed (due to dual-life modules,
-apparently). This is considered normal.
+probably get an email that indexing has failed, due to module permissions.
+This is considered normal.
Do not proceed any further until you are sure that your tarballs are on
CPAN. Check your authors directory on one of the "fast" CPAN mirrors
-(e.g. cpan.shadowcatprojects.net, cpan.dagolden.com, cpan.hexten.net
+(e.g., cpan.hexten.net
or cpan.cpantesters.org) to confirm that your uploads have been successful.
=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[] = {
=item *
-Wait 24 hours or so, then post the announcement to use.perl.org.
-(if you don't have access rights to post news, ask someone like Rafael to
-do it for you.)
-
-=item *
-
-Check http://www.cpan.org/src/ to see if the new tarballs have appeared.
-They should appear automatically, but if they don't then ask Jarkko to look
-into it, since his scripts must have broken.
-
-=item *
-
-I<You MUST SKIP this step for RC, BLEAD>
-
-Ask Jarkko to update the descriptions of which tarballs are current in
-http://www.cpan.org/src/README.html, and Rafael to update
-http://dev.perl.org/perl5/
-
-=item *
-
I<You MUST SKIP this step for RC>
Remind the current maintainer of C<Module::CoreList> to push a new release
I<You MUST SKIP this step for RC>
-Bump the perlXYZdelta version number.
+Create a new perldelta.
-First, create a new empty perlNNNdelta.pod file for the current release + 1;
-see F<Porting/how_to_write_a_perldelta.pod>.
+First, update the F<.gitignore> file in the F<pod/> folder to ignore the next
+release's generated F<pod/perlNNNdelta.pod> file rather than this releases's
+one which we are about to set in stone (where NNN is the perl version number
+without the dots. i.e. 5135 for 5.13.5).
-You should be able to do this by just copying in a skeleton template and
-then doing a quick fix up of the version numbers, e.g.
+Then, move the existing F<pod/perldelta.pod> to F<pod/perlNNNdelta.pod>.
-Then commit this file. (If this new perldelta needs to get cherrypicked
-anywhere, this provides a clean base to merge from.)
+Now edit the moved delta file to change the C<NAME> from C<perldelta> to
+C<perlNNNdelta>.
-For example, assuming 5.10.2:
+Then create a new empty perldelta.pod file for the new release; see
+F<Porting/how_to_write_a_perldelta.pod>.
- $ cp -i Porting/perldelta_template.pod pod/perl5102delta.pod
- $ (edit it)
- $ git add pod/perl5102delta.pod
- $ git commit -m 'create perl5102delta'
+You should be able to do this by just copying in a skeleton template and
+then doing a quick fix up of the version numbers.
-Edit the previous delta file to change the C<NAME> from C<perldelta>
-to C<perlNNNdelta> and commit it. For example:
+Then commit the move and the new file.
+For example, assuming you just released 5.10.1:
+
+ $ git mv pod/perldelta.pod pod/perl5101delta.pod
+ $ (edit pod/perl5101delta.pod to retitle)
$ git add pod/perl5101delta.pod
- $ git commit -m 'retitle perl5101delta'
+
+ $ cp -i Porting/perldelta_template.pod pod/perldelta.pod
+ $ (edit pod/perldelta.pod)
+ $ git add pod/perldelta.pod
+ $ git commit -m 'create perldelta for 5.10.2'
Now you need to update various tables of contents, 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:
+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
+ -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
Run C<perl pod/buildtoc --build-all> to update the F<perldelta> version in
win32/makefile.mk
win32/pod.mak
-Then manually edit (F<vms/descrip_mms.template> to bump the version
-in the following entry:
-
- [.pod]perldelta.pod : [.pod]perl5101delta.pod
-
-XXX this previous step needs to fixed to automate it in pod/buildtoc.
-
-Manually update references to the perlNNNdelta version in these files:
-
- INSTALL
- README
-
-These two lists of files probably aren't exhaustive; do a recursive grep
-on the previous filename to look for suitable candidates that may have
-been missed.
-
Finally, commit:
- $ git commit -a -m 'update TOC and perldelta references'
+ $ 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 ca8de22071 for an example of a
+see if they look similar. See commit 2b6e134265 for an example of a
previous version bump.
=item *
I<You MUST SKIP this step for RC, BLEAD>
-Copy the perlNNNdelta.pod for this release into the other branches; for
+Copy the perldelta.pod for this release into the other branches; for
example:
- $ cp -i ../5.10.x/pod/perl5101delta.pod pod/ # for example
+ $ cp -i ../5.10.x/pod/perldelta.pod pod/perl5101delta.pod # for example
$ git add pod/perl5101delta.pod
Edit F<pod.lst> to add an entry for the file, e.g.:
=back
+=head2 Building a release - the day after
+
+=over 4
+
+=item *
+
+Check your author directory under L<http://www.cpan.org/authors/id/>
+to ensure that the tarballs are available on the website.
+
+=item *
+
+Check C</src> on CPAN (on a fast mirror) to ensure that links to
+the new tarballs have appeared. There should be links in C</src/5.0>
+(which is accumulating all new versions), links in C</src> (which shows
+only the latest version on each branch), and an appropriate mention in
+C</src/README.html> (which describes the latest versions).
+
+These links should appear automatically, some hours after upload.
+If they don't, or the C<README.html> description is inadequate,
+ask Ask <ask@perl.org>.
+
+=item *
+
+Check L<http://www.cpan.org/src/> to ensure that the C</src> updates
+have been correctly mirrored to the website.
+If they haven't, ask Ask <ask@perl.org>.
+
+=item *
+
+Check L<http://search.cpan.org> to see if it has indexed the distribution.
+It should be visible at a URL like C<http://search.cpan.org/dist/perl-5.10.1/>.
+
+=item *
+
+I<This step ONLY for STABLE>
+
+Ask Rafael to update L<http://dev.perl.org/perl5/>.
+
+=back
+
=head1 SOURCE
Based on
https://perl5.git.perl.org / perl5.git / blobdiff