release_managers_guide - Releasing a new version of perl 5.x
-XXX as of Jul 2009, this file is still a work-in-progress. I think it
-contains all the actions needed to build a release, but things may have
-got skipped, and some things could do with polishing. Note that things
-change each release, there may be new things not covered here, or
-tools may need updating. DAPM
+As of August 2009, this file is mostly complete, although it is missing
+some detail on doing a major release (e.g. 5.10.0 -> 5.12.0). Note that
+things change at each release, so there may be new things not covered
+here, or tools may need updating.
=head1 SYNOPSIS
release candidate, or final, numbered release of maint or blead.
The release process has traditionally been executed by the current
-pumpking.
+pumpking. Blead releases from 5.11.0 forward are made each month on the
+20th by a non-pumpking release engineer. The release engineer roster
+and schedule can be found in Porting/release_schedule.pod.
This document both helps as a check-list for the release engineer
and is a base for ideas on how the various tasks could be automated
=item Release Candidate (RC)
-XXX Describe me
+A release candidate is an attempt to produce a tarball that is a close as
+possible to the final release. Indeed, unless critical faults are found
+during the RC testing, the final release will be identical to the RC
+barring a few minor fixups (updating the release date in F<perlhist.pod>,
+removing the RC status from F<patchlevel.h>, etc). If faults are found,
+then the fixes should be put into a new release candidate, never directly
+into a final release.
=item Stable/Maint release
The work of building a release candidate for a numbered release of
perl generally starts several weeks before the first release candidate.
-Some of these should be done regularly, but all I<must> be done in the
-runup to a release.
+Some of the following steps should be done regularly, but all I<must> be
+done in the run up to a release.
=over 4
$ ./perl -Ilib Porting/core-cpan-diff -x -a
-if you are making a maint release, run C<core-cpan-diff> on both blead and
+If you are making a maint release, run C<core-cpan-diff> on both blead and
maint, then diff the two outputs. Compare this with what you expect, and if
necessary, fix things up. For example, you might think that both blead
and maint are synchronised with a particular CPAN module, but one might
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 dir looking for likely candidates:
+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
-This produces a file containing a list of suggested edits, eg:
+This produces a file containing a list of suggested edits, e.g.:
NetWare/Makefile
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. 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:
+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:
$ Porting/bump-perl-version -u < /tmp/scan
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. Also note that this tool currently only
-performs a single change per line, so in particular, this line in
-README.vms needs special handling:
+some of which need to be left unchanged. 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
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
correct incantation: replace the not-yet-created tag with C<HEAD> and see
-if git log produces roughly the right number of commits across roughly the
-right time period.
-
+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).
=item *
-Check some more build configurations, e.g.
+Check some more build configurations. The check that setuid builds and
+installs is for < 5.11.0 only.
+
+ $ sh Configure -Dprefix=/tmp/perl-5.x.y -Uinstallusrbinperl \
+ -Duseshrplib -Dd_dosuid
+ $ make
+ $ LD_LIBRARY_PATH=`pwd` make test # or similar for useshrplib
- -Duseshrplib -Dd_dosuid
- make suidperl
+ $ make suidperl
+ $ su -c 'make install'
+ $ ls -l .../bin/sperl
+ -rws--x--x 1 root root 69974 2009-08-22 21:55 .../bin/sperl
-Check that setuid installs works (for < 5.11.0 only).
-XXX any other configs?
+(Then delete the installation directory.)
+XXX think of other configurations that need testing.
=item *
$ git log | perl Porting/checkAUTHORS.pl --acknowledged AUTHORS -
-=item *
-
-I<You MAY SKIP this step for SNAPSHOT>
-
-As there are no regular smokes [ XXX yet - please fix?] find out about the
-state of the current branch on VMS. If the branch you're releasing on
-is failing tests on VMS, you may not want to do a release.
-
=back
=head2 Building a release - on the day
=item *
-Configure and build perl so that you have a Makefile and porting tools:
+I<You MAY SKIP this step for SNAPSHOT>
- $ ./Configure -Dusedevel -des
- $ make
+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
+
+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
+
+=item *
+
+Make sure you have a gitwise-clean perl directory (no modified files,
+unpushed commits etc):
+
+ $ git status
+
+=item *
-XXX probably want some re-ordering here: we build a perl, and very soon
-afterwards do a distclean
+If not already built, Configure and build perl so that you have a Makefile
+and porting tools:
+
+ $ ./Configure -Dusedevel -des && make
=item *
$ make regen_perly
$ git status
-If any of the files managed by regen.pl have changed, then you should commit
-the updated versions:
-
- $ git commit -m 'Updated files generated by regen tools for perl 5.x.y' <list of files>
+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'
=item *
$ rm META.yml
$ make META.yml
+ $ git diff
+
+XXX it would be nice to make Porting/makemeta use regen_lib.pl
+to get the same 'update the file if its changed' functionality
+we get with 'make regen' etc.
Commit META.yml if it has changed:
- $ git commit -m 'Updating META.yml in preparation for release of 5.x.y' META.yml
+ $ git commit -m 'Update META.yml' META.yml
=item *
-Check that the manifest is sorted and correct:
+I<You MUST SKIP this step for SNAPSHOT>
- $ make manisort
- $ make distclean
- $ perl Porting/manicheck
+Update C<Module::Corelist> with module version data for the new release.
+Note that if this is a maint release, you should run the following actions
+from the maint directory, but commit the C<Corelist.pm> changes in
+I<blead> and subsequently cherry-pick it.
-Commit MANIFEST if it has changed:
+F<corelist.pl> uses ftp.funet.fi to verify information about dual-lived
+modules on CPAN. It can use a full, local CPAN mirror or fall back
+to C<wget> or C<curl> to fetch only package metadata remotely.
- $ git commit -m 'Updating MANIFEST in preparation for release of 5.x.y' MANIFEST
+(If you'd prefer to have a full CPAN mirror, see
+http://www.cpan.org/misc/cpan-faq.html#How_mirror_CPAN)
+Then change to your perl checkout, and if necessary,
+ $ make perl
-=item *
+If this not the first update for this version, first edit
+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.
-I<You MUST SKIP this step for SNAPSHOT>
+XXX the edit-in-place functionality of Porting/corelist.pl should
+be fixed to handle this automatically.
-Add an entry to F<pod/perlhist.pod> with the current date:
+Then, If you have a local CPAN mirror, run:
- 5.8.9-RC1 2008-Nov-10
+ $ ./perl -Ilib Porting/corelist.pl ~/my-cpan-mirror
-Make sure the correct pumpking is listed, and if this is the first release
-under the stewardship of a new pumpking, make sure that his or her name
-is listed in the section entitled C<THE KEEPERS OF THE PUMPKIN>.
+Otherwise, run:
-Be sure to commit your changes:
+ $ ./perl -Ilib Porting/corelist.pl cpan
+
+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<ext/Module-CoreList/lib/Module/CoreList.pm>.
+
+Check that file over carefully:
- $ git commit -m 'Updating perlhist in preparation for release of 5.x.y pod/perlhist.pod
+ $ 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
+appear in the final release, and leave as-is for the later RCs and final).
+
+Edit the version number in the new C<< 'Module::CoreList' => 'X.YZ' >>
+entry, as that is likely to reflect the previous version number.
+
+In addition, if this is a final release (rather than a release candidate):
+
+=over 4
=item *
-I<You MAY SKIP this step for SNAPSHOT>
+Update this version's entry in the C<%released> hash with today's date.
-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.
+=item *
- podchecker -warnings -warnings pod/perl5101delta.pod
- spell pod/perl5101delta.pod
+Make sure that the script has correctly updated the C<CAVEATS> section
-Also, you may want to generate and view an HTML version of it to check
-formatting, e.g.
+=back
- perl pod/pod2html pod/perl5101delta.pod > /tmp/perl5101delta.html
+Finally, commit the new version of Module::CoreList:
+(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' dist/Module-CoreList/lib/Module/CoreList.pm
=item *
-I<You MUST SKIP this step for SNAPSHOT>
+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
-Update patchlevel.h to add a C<-RC1>-or-whatever string; or, if this is a
-final release, remove it. [ XXX how now?? see 34813 for old way ]
+Commit MANIFEST if it has changed:
+
+ $ git commit -m 'Update MANIFEST' MANIFEST
=item *
I<You MUST SKIP this step for SNAPSHOT>
-Update C<Module::Corelist>.
+Add an entry to F<pod/perlhist.pod> with the current date, e.g.:
-Note that if this is a maint release, you should run the following actions
-from the maint directory, but commit the C<Corelist.pm> changes in
-I<blead> and subsequently cherry-pick it.
+ David 5.10.1-RC1 2009-Aug-06
-corelist.pl uses ftp.funet.fi to verify information about dual-lifed
-modules on CPAN. It can use a full, local CPAN mirror or fall back
-to C<wget> or C<curl> to fetch only package metadata remotely.
+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
+sure that his or her name is listed in the section entitled
+C<THE KEEPERS OF THE PUMPKIN>.
-(If you'd prefer to have a full CPAN mirror, see
-http://www.cpan.org/misc/cpan-faq.html#How_mirror_CPAN)
+Be sure to commit your changes:
+ $ git commit -m 'add new release to perlhist' pod/perlhist.pod
-Then change to your perl checkout.
+=item *
-If you have a local CPAN mirror, run:
+I<You MUST SKIP this step for SNAPSHOT>
- $ make perl
- $ ./perl -Ilib Porting/corelist.pl ~/my-cpan-mirror
+Update F<patchlevel.h> to add a C<-RC1>-or-whatever string; or, if this is
+a final release, remove it. For example:
-Otherwise, run:
+ static const char * const local_patches[] = {
+ NULL
+ + ,"RC1"
+ PERL_GIT_UNPUSHED_COMMITS /* do not remove this line */
- $ make perl
- $ ./perl -Ilib Porting/corelist.pl cpan
+Be sure to commit your change:
-This will chug for a while. Assuming all goes well, it will
-update lib/Module/CoreList.pm.
+ $ git commit -m 'bump version to RCnnn' patchlevel.h
-Check that file over carefully:
+=item *
- $ git diff lib/Module/CoreList.pm
+Build perl, then make sure it passes its own test suite, and installs:
+ $ git clean -xdf
+ $ ./Configure -des -Dprefix=/tmp/perl-5.x.y-pretest
-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).
+ # or if it's an odd-numbered version:
+ $ ./Configure -des -Dusedevel -Dprefix=/tmp/perl-5.x.y-pretest
-Edit the version number in the new C<< 'Module::CoreList' => 'X.YZ' >>
-entry, as that is likely to reflect the previous version number.
+ $ make test install
-If this is a final release (rather than a release candidate):
+=item *
-=over 4
+Check that the output of C</tmp/perl-5.x.y-pretest/bin/perl -v> and
+C</tmp/perl-5.x.y-pretest/bin/perl -V> are as expected,
+especially as regards version numbers, patch and/or RC levels, and @INC
+paths. Note that as they have been been built from a git working
+directory, they will still identify themselves using git tags and
+commits.
+
+Then delete the temporary installation.
=item *
-Update this version's entry in the C<%released> hash with today's date.
+If this is maint release, make sure F<Porting/mergelog> is saved and
+committed.
=item *
-Make sure that the script has correctly updated the C<CAVEATS> section
-
-=back
+Push all your recent commits:
-Finally, commit the new version of Module::CoreList:
+ $ git push origin ....
- $ git commit -m 'Updated Module::CoreList for the 5.x.y release' \
- lib/Module/Corelist.pm
=item *
-Build perl, then make sure it passes its own test suite, and installs:
+I<You MUST SKIP this step for SNAPSHOT>
- $ ./Configure -des -Dusedevel -Dprefix=/tmp/perl-5.x.y-pretest
- $ make test install
+Tag the release:
+
+ $ git tag v5.11.0 -m'First release of the v5.11 series!'
+
+It is VERY important that from this point forward, you not push
+your git changes to the Perl master repository. If anything goes
+wrong before you publish your newly-created tag, you can delete
+and recreate it. Once you push your tag, we're stuck with it
+and you'll need to use a new version number for your release.
=item *
$ cd root/of/perl/tree
$ make distclean
- $ git clean -xdf # make sure perl and git agree on files
+ $ git clean -xdf # make sure perl and git agree on files
+ $ git status # and there's nothing lying around
$ perl Porting/makerel -b -s `git describe` # for a snapshot
$ perl Porting/makerel -b -s RC1 # for a release candidate
adds DOS line endings to some, then tars it up as
F<../perl-x.y.z-RC1.tar.gz>. With C<-b>, it also creates a C<tar.bz2> file.
+
XXX if we go for extra tags and branches stuff, then add the extra details
here
=item *
+Clean up the temporary directory, e.g.
+
+ $ rm -rf ../perl-x.y.z-RC1
+
+=item *
+
Copy the tarballs (.gz and possibly .bz2) to a web server somewhere you
have access to.
Check that the test harness and install work on each test machine:
+ $ make distclean
$ ./Configure -des -Dprefix=/install/path && make all test_harness install
+ $ cd /install/path
=item *
=item *
+Run the Installation Verification Procedure utility:
+
+ $ bin/perlivp
+ ...
+ All tests successful.
+ $
+
+=item *
+
+Compare the pathnames of all installed files with those of the previous
+release (i.e. against the last installed tarball on this branch which you
+have previously verified using this same procedure). In particular, look
+for files in the wrong place, or files no longer included which should be.
+For example, suppose the about-to-be-released version is 5.10.1 and the
+previous is 5.10.0:
+
+ cd installdir-5.10.0/
+ find . -type f | perl -pe's/5\.10\.0/5.10.1/g' | sort > /tmp/f1
+ cd installdir-5.10.1/
+ find . -type f | sort > /tmp/f2
+ diff -u /tmp/f[12]
+
+=item *
+
Bootstrap the CPAN client on the clean install:
- $ ./bin/perl -MCPAN -e'shell'
+ $ bin/perl -MCPAN -e'shell'
=item *
-Install Inline.pm
+Try installing a popular CPAN module that's reasonably complex and that
+has dependencies; for example:
- $ ./bin/perl -MCPAN -e'install Inline'
+ CPAN> install Inline
+ CPAN> quit
Check that your perl can run this:
- $ ./bin/perl -lwe 'use Inline C => "int answer() { return 42;} "; print answer'
+ $ bin/perl -lwe 'use Inline C => "int f() { return 42;} "; print f'
+ 42
+ $
=item *
Bootstrap the CPANPLUS client on the clean install:
- $ ./bin/cpanp
+ $ bin/cpanp
+=item *
+
+Install an XS module, for example:
+
+ CPAN Terminal> i DBI
+ CPAN Terminal> quit
+ $ bin/perl -MDBI -e 1
+ $
=item *
-Install an XS module.
+I<If you're building a SNAPSHOT, you should STOP HERE>
=item *
-If all is well, announce the snapshot to p5p. (For a release candidate,
-instead follow the further steps described later.)
+Check that the C<perlbug> utility works. Try the following:
+ $ bin/perlbug
+ ...
+ Subject: test bug report
+ Local perl administrator [yourself]:
+ Editor [vi]:
+ Module:
+ Category [core]:
+ Severity [low]:
+ (edit report)
+ Action (Send/Display/Edit/Subject/Save to File): f
+ Name of file to save message in [perlbug.rep]:
+ Action (Send/Display/Edit/Subject/Save to File): q
-=item *
+and carefully examine the output (in F<perlbug.rep]>), especially
+the "Locally applied patches" section. If everything appears okay, then
+delete the file, and try it again, this time actually submitting the bug
+report. Check that it shows up, then remember to close it!
-I<You MAY SKIP this step for SNAPSHOT>
+=item *
Wait for the smoke tests to catch up with the commit which this release is
based on (or at least the last commit of any consequence).
=item *
-I<You MUST SKIP this step for SNAPSHOT>
-
Once smoking is okay, upload it to PAUSE. This is the point of no return.
If anything goes wrong after this point, you will need to re-prepare
a new release with a new minor version or RC number.
-You may wish to create a .bz2 version of the tarball and upload that too.
+ https://pause.perl.org/
-=item *
+(Login, then select 'Upload a file to CPAN')
-I<You MUST SKIP this step for SNAPSHOT>
+Upload both the .gz and .bz2 versions of the tarball.
-Create a tag for the exact git revision you built the release from.
-C<commit> below is the commit corresponding to the tarball. It can be
-omitted if there have been no further commits since the tarball was
-created.
+=item *
+
+Now that you've shipped the new perl release to PAUSE, it's
+time to publish the tag you created earlier to the public git repo:
- $ git tag perl-5.10.1-RC1 -m'Release Candidate 1 of Perl 5.10.1' <commit>
- $ git push origin tag perl-5.10.1-RC1
+ $ git push origin tag v5.11.0
=item *
-I<You MUST SKIP this step for SNAPSHOT>
+Disarm the F<patchlevel.h> change; for example,
+
+ static const char * const local_patches[] = {
+ NULL
+ - ,"RC1"
+ PERL_GIT_UNPUSHED_COMMITS /* do not remove this line */
+
+Be sure to commit your change:
+
+ $ git commit -m 'disarm RCnnn bump' patchlevel.h
+ $ git push origin ....
-Disarm the patchlevel.h change [ XXX expand ]
=item *
=item *
-I<You MAY SKIP this step for SNAPSHOT>
-
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 *
-I<You MUST SKIP this step for SNAPSHOT, RC, BLEAD>
+Ask Jarkko to add the tarball to http://www.cpan.org/src/
-Ask Jarkko to update 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, 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 SNAPSHOT, RC>
+I<You MUST SKIP this step for RC>
-Create a new empty perlNNNdelta.pod file for the current release + 1;
-see F<Porting/how_to_write_a_perldelta.pod>.
-[ XXX Perhaps we should have an empty template file we can copy in. ]
+Remind the current maintainer of C<Module::CoreList> to push a new release
+to CPAN.
-In addition, edit F<pod.lst>, adding the new entry as 'D', and unmark previous
-entry as 'D',
+=item *
-Change perlNNNdelta references to the new version in these files
+I<You MUST SKIP this step for RC>
- INSTALL
- win32/Makefile.mk
- win32/Makefile
- Makefile.SH
- README
+Bump the perlXYZ version number.
-Also, edit the previous delta file to change the C<NAME> from C<perldelta>
-to C<perlNNNdelta>.
+First, create a new empty perlNNNdelta.pod file for the current release + 1;
+see F<Porting/how_to_write_a_perldelta.pod>.
-These two lists of files probably aren't exhaustive; do a recursive grep
-on the previous filename to look for suitable candidates.
+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.
-(see 16410843ea for an example).
+ $ cp -i Porting/perldelta_template pod/perl5102delta.pod
+ $ (edit it)
+ $ git add pod/perl5102delta.pod
-=item *
+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
-Run C<perl pod/buildtoc --build-all> to update the following files:
+Run C<perl pod/buildtoc --build-all> to update the F<perldelta> version in
+the following files:
MANIFEST
+ Makefile.SH
+ pod.lst
pod/perl.pod
- win32/pod.mak
vms/descrip_mms.template
+ win32/Makefile
+ win32/makefile.mk
+ win32/pod.mak
-If you modified perldelta.pod, (F<vms/descrip_mms.template> will
-needs a manual edit to bump the C<perldelta.pod> entry - it would
-be good for someone to figure out the fix.)
+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
+
+Edit the previous delta file to change the C<NAME> from C<perldelta>
+to C<perlNNNdelta>.
+
+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 'create perlXXXdelta'
+
+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
+previous version bump.
=item *
-I<You MUST SKIP this step for SNAPSHOT, RC, BLEAD>
+I<You MUST SKIP this step for RC, BLEAD>
If this was a maint release, then edit F<Porting/mergelog> to change
all the C<d> (deferred) flags to C<.> (needs review).
=item *
-I<You MUST SKIP this step for SNAPSHOT, RC, BLEAD>
+I<You MUST SKIP this step for RC, BLEAD>
If this was a major release (5.x.0), then create a new maint branch
based on the commit tagged as the current release and bump the version
=item *
-I<You MUST SKIP this step for SNAPSHOT, RC, BLEAD>
+I<You MUST SKIP this step for RC, BLEAD>
-Copy the perlNNNdelta.pod for this release into the other branches, and
-remember to update these files on those branches too:
+Copy the perlNNNdelta.pod for this release into the other branches; for
+example:
- MANIFEST
- pod.lst
- pod/perl.pod
- vms/descrip_mms.template
- win32/pod.mak
+ $ cp -i ../5.10.x/pod/perl5101delta.pod pod/ # for example
+ $ git add pod/perl5101delta.pod
-(see fc5be80860 for an example).
+Edit F<pod.lst> to add an entry for the file, e.g.:
-=item *
+ perl5101delta Perl changes in version 5.10.1
-I<You MUST SKIP this step for SNAPSHOT>
+Then rebuild various files:
+
+ $ perl pod/buildtoc --build-all
+
+Finally, commit:
+
+ $ git commit -a -m 'add perlXXXdelta'
+
+=item *
Make sure any recent F<pod/perlhist.pod> entries are copied to
F<perlhist.pod> on other branches; typically the RC* and final entries,
=item *
-I<You MUST SKIP this step for SNAPSHOT, RC>
-
-Remind the current maintainer of C<Module::CoreList> to push a new release
-to CPAN.
-
-=item *
-
-I<You MUST RETIRE to your preferred PUB, CAFE or SEASIDE VILLA for some much-needed
-rest and relaxation>.
+I<You MUST RETIRE to your preferred PUB, CAFE or SEASIDE VILLA for some
+much-needed rest and relaxation>.
Thanks for releasing perl!
projects / p5sagit/p5-mst-13.2.git / blobdiff