This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
In the release guide, mention the AdvanceCOMP can compress gzip files better.
[perl5.git] / Porting / release_managers_guide.pod
1 =encoding utf8
2
3 =head1 NAME
4
5 release_managers_guide - Releasing a new version of perl 5.x
6
7 As of August 2009, this file is mostly complete, although it is missing
8 some detail on doing a major release (e.g. 5.10.0 -> 5.12.0). Note that
9 things change at each release, so there may be new things not covered
10 here, or tools may need updating.
11
12 =head1 SYNOPSIS
13
14 This document describes the series of tasks required - some automatic, some
15 manual - to produce a perl release of some description, be that a snaphot,
16 release candidate, or final, numbered release of maint or blead.
17
18 The release process has traditionally been executed by the current
19 pumpking. Blead releases from 5.11.0 forward are made each month on the
20 20th by a non-pumpking release engineer.  The release engineer roster
21 and schedule can be found in Porting/release_schedule.pod.
22
23 This document both helps as a check-list for the release engineer 
24 and is a base for ideas on how the various tasks could be automated 
25 or distributed.
26
27 The outline of a typical release cycle is as follows:
28
29     (5.10.1 is released, and post-release actions have been done)
30
31     ...time passes...
32
33     an occasional snapshot is released, that still identifies itself as
34         5.10.1
35
36     ...time passes...
37
38     a few weeks before the release, a number of steps are performed,
39         including bumping the version to 5.10.2
40
41     ...a few weeks passes...
42
43     perl-5.10.2-RC1 is released
44
45     perl-5.10.2 is released
46
47     post-release actions are performed, including creating new
48         perldelta.pod
49
50     ... the cycle continues ...
51
52 =head1 DETAILS
53
54 Some of the tasks described below apply to all four types of 
55 release of Perl. (snapshot, RC, final release of maint, final 
56 release of blead). Some of these tasks apply only to a subset
57 of these release types.  If a step does not apply to a given 
58 type of release, you will see a notation to that effect at
59 the beginning of the step.
60
61 =head2 Release types
62
63 =over 4
64
65 =item Snapshot
66
67 A snapshot is intended to encourage in-depth testing from time-to-time,
68 for example after a key point in the stabilisation of a branch. It
69 requires fewer steps than a full release, and the version number of perl in
70 the tarball will usually be the same as that of the previous release.
71
72 =item Release Candidate (RC)
73
74 A release candidate is an attempt to produce a tarball that is a close as
75 possible to the final release. Indeed, unless critical faults are found
76 during the RC testing, the final release will be identical to the RC
77 barring a few minor fixups (updating the release date in F<perlhist.pod>,
78 removing the RC status from F<patchlevel.h>, etc). If faults are found,
79 then the fixes should be put into a new release candidate, never directly
80 into a final release.
81
82 =item Stable/Maint release
83
84 At this point you should have a working release candidate with few or no
85 changes since.
86
87 It's essentially the same procedure as for making a release candidate, but
88 with a whole bunch of extra post-release steps.
89
90 =item Blead release
91
92 It's essentially the same procedure as for making a release candidate, but
93 with a whole bunch of extra post-release steps.
94
95 =back
96
97 =head2 Prerequisites
98
99 Before you can make an official release of perl, there are a few
100 hoops you need to jump through:
101
102 =over 4
103
104 =item PAUSE account
105
106 I<SKIP this step for SNAPSHOT>
107
108 Make sure you have a PAUSE account suitable for uploading a perl release.
109 If you don't have a PAUSE account, then request one:
110
111     https://pause.perl.org/pause/query?ACTION=request_id
112
113 Check that your account is allowed to upload perl distros: go to
114 L<https://pause.perl.org/pause/authenquery?ACTION=who_pumpkin> and check that
115 your PAUSE ID is listed there.  If not, ask Andreas KE<0xf6>nig to add your ID
116 to the list of people allowed to upload something called perl.  You can find
117 Andreas' email address at:
118
119     https://pause.perl.org/pause/query?ACTION=pause_04imprint
120
121 =item search.cpan.org
122
123 Make sure that search.cpan.org knows that you're allowed to upload
124 perl distros. Contact Graham Barr to make sure that you're on the right
125 list.
126
127 =item CPAN mirror
128
129 Some release engineering steps require a full mirror of the CPAN.
130 Work to fall back to using a remote mirror via HTTP is incomplete
131 but ongoing. (No, a minicpan mirror is not sufficient)
132
133 =item git checkout and commit bit
134
135 You will need a working C<git> installation, checkout of the perl
136 git repository and perl commit bit.  For information about working
137 with perl and git, see F<pod/perlgit.pod>.
138
139 If you are not yet a perl committer, you won't be able to make a
140 release.  Have a chat with whichever evil perl porter tried to talk
141 you into the idea in the first place to figure out the best way to
142 resolve the issue.
143
144
145 =item Quotation for release announcement epigraph
146
147 I<SKIP this step for SNAPSHOT and RC>
148
149 For a numbered blead or maint release of perl, you will need a quotation 
150 to use as an epigraph to your release announcement.  (There's no harm
151 in having one for a snapshot, but it's not required).
152
153
154 =back
155
156
157 =head2 Building a release - advance actions
158
159 The work of building a release candidate for a numbered release of
160 perl generally starts several weeks before the first release candidate.
161 Some of the following steps should be done regularly, but all I<must> be
162 done in the run up to a release.
163
164 =over 4
165
166 =item *
167
168 I<You MAY SKIP this step for SNAPSHOT>
169
170 Ensure that dual-life CPAN modules are synchronised with CPAN.  Basically,
171 run the following:
172
173     $ ./perl -Ilib Porting/core-cpan-diff -a -o /tmp/corediffs
174
175 to see any inconsistencies between the core and CPAN versions of distros,
176 then fix the core, or cajole CPAN authors as appropriate. See also the
177 C<-d> and C<-v> options for more detail.  You'll probably want to use the
178 C<-c cachedir> option to avoid repeated CPAN downloads and may want to
179 use C<-m file:///mirror/path> if you made a local CPAN mirror.
180
181 To see which core distro versions differ from the current CPAN versions:
182
183     $ ./perl -Ilib Porting/core-cpan-diff -x -a
184
185 If you are making a maint release, run C<core-cpan-diff> on both blead and
186 maint, then diff the two outputs. Compare this with what you expect, and if
187 necessary, fix things up. For example, you might think that both blead
188 and maint are synchronised with a particular CPAN module, but one might
189 have some extra changes. 
190
191 =item *
192
193 I<You MAY SKIP this step for SNAPSHOT>
194
195 Ensure dual-life CPAN modules are stable, which comes down to:
196
197     for each module that fails its regression tests on $current
198         did it fail identically on $previous?
199         if yes, "SEP" (Somebody Else's Problem)
200         else work out why it failed (a bisect is useful for this)
201
202     attempt to group failure causes
203
204     for each failure cause
205         is that a regression?
206         if yes, figure out how to fix it
207             (more code? revert the code that broke it)
208         else
209             (presumably) it's relying on something un-or-under-documented
210             should the existing behaviour stay?
211                 yes - goto "regression"
212                 no - note it in perldelta as a significant bugfix
213                 (also, try to inform the module's author)
214
215 =item *
216
217 I<You MAY SKIP this step for SNAPSHOT>
218
219 Similarly, monitor the smoking of core tests, and try to fix.  See
220 L<http://doc.procura.nl/smoke/index.html> for a summary. See also
221 L<http://www.nntp.perl.org/group/perl.daily-build.reports/> which has
222 the raw reports.
223
224 =item *
225
226 I<You MAY SKIP this step for SNAPSHOT>
227
228 Similarly, monitor the smoking of perl for compiler warnings, and try to
229 fix.
230
231 =item *
232
233 I<You MAY SKIP this step for SNAPSHOT>
234
235 Get perldelta in a mostly finished state.
236
237 Read  F<Porting/how_to_write_a_perldelta.pod>, and try to make sure that
238 every section it lists is, if necessary, populated and complete. Copy
239 edit the whole document.
240
241 =item *
242
243 I<You MUST SKIP this step for SNAPSHOT>
244
245 Bump the version number (e.g. from 5.12.0 to 5.12.1).
246
247 For a blead release, this can happen on the day of the release.  For a
248 release candidate for a stable perl, this should happen a week or two
249 before the first release candidate to allow sufficient time for testing and
250 smoking with the target version built into the perl executable. For
251 subsequent release candidates and the final release, it it not necessary to
252 bump the version further.
253
254 There is a tool to semi-automate this process. It works in two stages.
255 First, it generates a list of suggested changes, which you review and
256 edit; then you feed this list back and it applies the edits. So, first
257 scan the source directory looking for likely candidates. The command line
258 arguments are the old and new version numbers, and -s means scan:
259
260     $ ./perl -Ilib Porting/bump-perl-version -s 5.10.0 5.10.1 > /tmp/scan
261
262 This produces a file containing a list of suggested edits, e.g.:
263
264     NetWare/Makefile
265
266        89: -MODULE_DESC     = "Perl 5.10.0 for NetWare"
267            +MODULE_DESC     = "Perl 5.10.1 for NetWare"
268
269 i.e. in the file F<NetWare/Makefile>, line 89 would be changed as shown.
270 Review the file carefully, and delete any -/+ line pairs that you don't
271 want changing. You can also edit just the C<+> line to change the
272 suggested replacement text. Remember that this tool is largely just
273 grepping for '5.10.0' or whatever, so it will generate false positives. Be
274 careful not change text like "this was fixed in 5.10.0"! Then run:
275
276     $ ./perl -Ilib Porting/bump-perl-version -u < /tmp/scan
277
278 which will update all the files shown.
279
280 Be particularly careful with F<INSTALL>, which contains a mixture of
281 C<5.10.0>-type strings, some of which need bumping on every release, and
282 some of which need to be left unchanged.
283 The line in F<INSTALL> about "is binary incompatible with" requires a
284 correct choice of earlier version to declare incompatibility with.
285
286 Also note that this tool
287 currently only detects a single substitution per line: so in particular,
288 this line in README.vms needs special handling:
289
290     rename perl-5^.10^.1.dir perl-5_10_1.dir
291
292 When doing a blead release, also make sure the C<PERL_API_*> constants in
293 F<patchlevel.h> are in sync with the version you're releasing, unless you're
294 absolutely sure the release you're about to make is 100% binary compatible
295 to an earlier release. When releasing a stable perl version, the C<PERL_API_*>
296 constants C<MUST NOT> be changed as we aim to guarantee binary compatibility
297 in maint branches.
298
299
300
301 Test your changes:
302
303     $ ./Configure -des -Dusedevel
304     $ make
305     $ make test
306
307 Commit your changes:
308
309     $ git st
310     $ git diff
311     B<review the delta carefully>
312
313     $ git commit -a -m 'Bump the perl version in various places for 5.x.y'
314
315 When the version number is bumped, you should also update Module::CoreList (as
316 described below in L<"Building a release - on the day">) to reflect the new
317 version number.
318
319 =item *
320
321 I<You MUST SKIP this step for SNAPSHOT>
322
323 Review and update INSTALL to account for the change in version number;
324 in particular, the "Coexistence with earlier versions of perl 5" section.
325
326 Be particularly careful with the section "Upgrading from 5.X.Y or earlier". For
327 stable releases, this needs to refer to the last release in the previous
328 development cycle. For blead releases, it needs to refer to the previous blead
329 release.
330
331 =item *
332
333 I<You MUST SKIP this step for SNAPSHOT>
334
335 Update the F<Changes> file to contain the git log command which would show
336 all the changes in this release. You will need assume the existence of a
337 not-yet created tag for the forthcoming release; e.g.
338
339     git log ... perl-5.10.0..perl-5.12.0
340
341 Due to warts in the perforce-to-git migration, some branches require extra
342 exclusions to avoid other branches being pulled in. Make sure you have the
343 correct incantation: replace the not-yet-created tag with C<HEAD> and see
344 if C<git log> produces roughly the right number of commits across roughly the
345 right time period (you may find C<git log --pretty=oneline | wc> useful).
346
347 =item *
348
349 Check some more build configurations. The check that setuid builds and
350 installs is for < 5.11.0 only.
351
352     $ sh Configure -Dprefix=/tmp/perl-5.x.y  -Uinstallusrbinperl \
353         -Duseshrplib -Dd_dosuid
354     $ make
355     $ LD_LIBRARY_PATH=`pwd` make test     # or similar for useshrplib
356
357     $ make suidperl
358     $ su -c 'make install'
359     $ ls -l .../bin/sperl
360     -rws--x--x 1 root root 69974 2009-08-22 21:55 .../bin/sperl
361
362 (Then delete the installation directory.)
363
364 XXX think of other configurations that need testing.
365
366 =item *
367
368 I<You MAY SKIP this step for SNAPSHOT>
369
370 L<perlport> has a section currently named I<Supported Platforms> that
371 indicates which platforms are known to build in the current release.
372 If necessary update the list and the indicated version number.
373
374 =back
375
376 =head2 Building a release - on the day
377
378 This section describes the actions required to make a release (or snapshot
379 etc) that are performed on the actual day.
380
381 =over 4
382
383 =item *
384
385 Review all the items in the previous section,
386 L<"Building a release - advance actions"> to ensure they are all done and
387 up-to-date.
388
389 =item *
390
391 For a blead release, if you did not bump the perl version number as part
392 of I<advance actions>, do that now.
393
394 =item *
395
396 I<You MAY SKIP this step for SNAPSHOT>
397
398 Finalize the perldelta.  In particular, fill in the Acknowledgements
399 section.  You can generate a list of contributors with checkAUTHORS.pl.
400 For example:
401
402   $ git log --pretty=fuller v5.13.${last}..HEAD | \
403     perl Porting/checkAUTHORS.pl --who -
404
405 Look at the previous L<perldelta> for how to write the opening
406 paragraph of the Acknowledgements section. To get the amount of
407 changed files and number of lines use this command:
408
409   $ git diff --shortstat v5.13.${last}..HEAD | \
410     ./perl -Ilib -nE 'my ($files, $insert, $delete) = /(\d+)/ga; say "$files files and ", $insert + $delete, " lines changed"'
411
412 Making sure to round off the number of lines changed.
413
414 Re-read the perldelta to try to find any embarrassing typos and thinkos;
415 remove any C<TODO> or C<XXX> flags; update the "Known Problems" section
416 with any serious issues for which fixes are not going to happen now; and
417 run through pod and spell checkers, e.g.
418
419     $ podchecker -warnings -warnings pod/perldelta.pod
420     $ spell pod/perldelta.pod
421
422 Also, you may want to generate and view an HTML version of it to check
423 formatting, e.g.
424
425     $ ./perl -Ilib ext/Pod-Html/pod2html pod/perldelta.pod > /tmp/perldelta.html
426
427 Another good HTML preview option is http://search.cpan.org/pod2html
428
429 If you make changes, be sure to commit them.
430
431 =item *
432
433 Make sure you have a gitwise-clean perl directory (no modified files,
434 unpushed commits etc):
435
436     $ git status
437     $ git clean -dxf
438
439 =item *
440
441 If not already built, Configure and build perl so that you have a Makefile
442 and porting tools:
443
444     $ ./Configure -Dusedevel -des && make
445
446 =item *
447
448 I<You MUST SKIP this step for SNAPSHOT>
449
450 Update C<Module::CoreList> with module version data for the new release.
451
452 Note that if this is a maint release, you should run the following actions
453 from the maint branch, but commit the C<CoreList.pm> changes in
454 I<blead> and subsequently cherry-pick it.  XXX need a better example
455
456 F<corelist.pl> uses ftp.funet.fi to verify information about dual-lived
457 modules on CPAN. It can use a full, local CPAN mirror or fall back
458 to C<wget> or C<curl> to fetch only package metadata remotely. (If you're
459 on Win32, then installing Cygwin is one way to have commands like C<wget>
460 and C<curl> available.)
461
462 (If you'd prefer to have a full CPAN mirror, see 
463 http://www.cpan.org/misc/cpan-faq.html#How_mirror_CPAN)
464
465 Then change to your perl checkout, and if necessary,
466
467     $ make
468
469 If this not the first update for this version (e.g. if it was updated
470 when the version number was originally bumped), first edit
471 F<dist/Module-CoreList/lib/Module/CoreList.pm> to delete the existing
472 entries for this version from the C<%released> and C<%version> hashes:
473 they will have a key like C<5.010001> for 5.10.1.
474
475 XXX the edit-in-place functionality of Porting/corelist.pl should
476 be fixed to handle this automatically.
477
478 Then, If you have a local CPAN mirror, run:
479
480     $ ./perl -Ilib Porting/corelist.pl ~/my-cpan-mirror
481
482 Otherwise, run:
483
484     $ ./perl -Ilib Porting/corelist.pl cpan
485
486 This will chug for a while, possibly reporting various warnings about
487 badly-indexed CPAN modules unrelated to the modules actually in core.
488 Assuming all goes well, it will update
489 F<dist/Module-CoreList/lib/Module/CoreList.pm>.
490
491 Check that file over carefully:
492
493     $ git diff dist/Module-CoreList/lib/Module/CoreList.pm
494
495 If necessary, bump C<$VERSION> (there's no need to do this for
496 every RC; in RC1, bump the version to a new clean number that will
497 appear in the final release, and leave as-is for the later RCs and final).
498
499 Edit the version number in the new C<< 'Module::CoreList' => 'X.YZ' >>
500 entry, as that is likely to reflect the previous version number.
501
502 Also edit Module::CoreList's new version number in its F<Changes>
503 file.
504
505 Add a perldelta entry for the new Module::CoreList version.
506
507 You should also add the version you're about to release to the
508 L<Module::CoreList/CAVEATS> section which enumerates the perl releases
509 that Module::CoreList covers.
510
511 In addition, if this is a final release (rather than a release candidate):
512
513 =over 4 
514
515 =item *
516
517 Update this version's entry in the C<%released> hash with today's date.
518
519 =item *
520
521 Make sure that the script has correctly updated the C<CAVEATS> section
522
523 =back
524
525 Finally, commit the new version of Module::CoreList:
526 (unless this is for maint; in which case commit it blead first, then
527 cherry-pick it back).
528
529     $ git commit -m 'Update Module::CoreList for 5.x.y' dist/Module-CoreList/lib/Module/CoreList.pm
530
531 =item *
532
533 Check that the manifest is sorted and correct:
534
535     $ make distclean
536     $ git clean -xdf # This shouldn't be necessary if distclean is correct
537     $ perl Porting/manicheck
538
539 If manicheck turns up anything wrong, update MANIFEST and begin this step again.
540
541     $ ./configure -des -Dusedevel
542     $ make test_porting
543     $ git commit -m 'Update MANIFEST' MANIFEST
544
545 =item *
546
547 I<You MUST SKIP this step for SNAPSHOT>
548
549 Add an entry to F<pod/perlhist.pod> with the current date, e.g.:
550
551     David    5.10.1-RC1    2009-Aug-06
552
553 Make sure that the correct pumpking is listed in the left-hand column, and
554 if this is the first release under the stewardship of a new pumpking, make
555 sure that his or her name is listed in the section entitled
556 C<THE KEEPERS OF THE PUMPKIN>.
557
558 Be sure to commit your changes:
559
560     $ git commit -m 'add new release to perlhist' pod/perlhist.pod
561
562 =item *
563
564 I<You MUST SKIP this step for SNAPSHOT or BLEAD release>
565
566 Update F<patchlevel.h> to add a C<-RC1>-or-whatever string; or, if this is
567 a final release, remove it. For example:
568
569      static const char * const local_patches[] = {
570              NULL
571     +        ,"RC1"
572              PERL_GIT_UNPUSHED_COMMITS /* do not remove this line */
573
574 Be sure to commit your change:
575
576     $ git commit -m 'bump version to RCnnn' patchlevel.h
577
578 =item *
579
580 Build perl, then make sure it passes its own test suite, and installs:
581
582     $ git clean -xdf
583     $ ./Configure -des -Dprefix=/tmp/perl-5.x.y-pretest
584
585     # or if it's an odd-numbered version:
586     $ ./Configure -des -Dusedevel -Dprefix=/tmp/perl-5.x.y-pretest
587
588     $ make test install
589
590 =item *
591
592 Check that the output of C</tmp/perl-5.x.y-pretest/bin/perl -v> and
593 C</tmp/perl-5.x.y-pretest/bin/perl -V> are as expected,
594 especially as regards version numbers, patch and/or RC levels, and @INC
595 paths. Note that as they have been been built from a git working
596 directory, they will still identify themselves using git tags and
597 commits.
598
599 Then delete the temporary installation.
600
601 =item *
602
603 Push all your recent commits:
604
605     $ git push origin ....
606
607
608 =item *
609
610 I<You MUST SKIP this step for SNAPSHOT>
611
612 Tag the release (e.g.):
613
614     $ git tag v5.11.0 -m "First release of the v5.11 series!"
615
616 It is VERY important that from this point forward, you not push
617 your git changes to the Perl master repository.  If anything goes
618 wrong before you publish your newly-created tag, you can delete
619 and recreate it.  Once you push your tag, we're stuck with it
620 and you'll need to use a new version number for your release.
621
622 =item *
623
624 Create a tarball. Use the C<-s> option to specify a suitable suffix for
625 the tarball and directory name:
626
627     $ cd root/of/perl/tree
628     $ make distclean
629     $ git clean -xdf            # make sure perl and git agree on files
630     $ git status                # and there's nothing lying around
631
632     $ perl Porting/makerel -b -s `git describe` # for a snapshot
633     $ perl Porting/makerel -b -s RC1            # for a release candidate
634     $ perl Porting/makerel -b                   # for a final release
635
636 This creates the  directory F<../perl-x.y.z-RC1> or similar, copies all
637 the MANIFEST files into it, sets the correct permissions on them,
638 adds DOS line endings to some, then tars it up as
639 F<../perl-x.y.z-RC1.tar.gz>. With C<-b>, it also creates a C<tar.bz2> file.
640
641 If you're getting your tarball suffixed with -uncommitted and you're sure
642 your changes were all committed, you can override the suffix with:
643
644     $ perl Porting/makerel -b -s ''
645
646 XXX if we go for extra tags and branches stuff, then add the extra details
647 here
648
649 Optionally, you might want to compress your tarball more. Unix F<gzip>
650 doesn't actually produce the smallest possible DEFLATE output. If you have the
651 AdvanceCOMP suite (e.g. the C<advancecomp> port on macports), you can run
652
653     $ advdef -z -4 ../perl-x.y.z-RC1.tar.gz
654
655 which will probably shrink your tarball by about 5%. Over the lifetime of
656 your distribution this will save a lot of people a small amount of download
657 time and disk space, which adds up.
658
659 (7-Zip on Windows is the same code as AdvanceCOMP, so Windows users get the
660 smallest files first time)
661
662 =item *
663
664 Clean up the temporary directory, e.g.
665
666     $ rm -rf ../perl-x.y.z-RC1
667
668 =item *
669
670 Copy the tarballs (.gz and possibly .bz2) to a web server somewhere you
671 have access to.
672
673 =item *
674
675 Download the tarball to some other machine. For a release candidate, 
676 you really want to test your tarball on two or more different platforms
677 and architectures. The #p5p IRC channel on irc.perl.org is a good place
678 to find willing victims.
679
680 =item *
681
682 Check that basic configuration and tests work on each test machine:
683
684     $ ./Configure -des && make all test
685
686 =item *
687
688 Check that the test harness and install work on each test machine:
689
690     $ make distclean
691     $ ./Configure -des -Dprefix=/install/path && make all test_harness install
692     $ cd /install/path
693
694 =item *
695
696 Check that the output of C<perl -v> and C<perl -V> are as expected,
697 especially as regards version numbers, patch and/or RC levels, and @INC
698 paths. 
699
700 Note that the results may be different without a F<.git/> directory,
701 which is why you should test from the tarball.
702
703 =item *
704
705 Run the Installation Verification Procedure utility:
706
707     $ ./perl utils/perlivp
708     ...
709     All tests successful.
710     $
711
712 =item *
713
714 Compare the pathnames of all installed files with those of the previous
715 release (i.e. against the last installed tarball on this branch which you
716 have previously verified using this same procedure). In particular, look
717 for files in the wrong place, or files no longer included which should be.
718 For example, suppose the about-to-be-released version is 5.10.1 and the
719 previous is 5.10.0:
720
721     cd installdir-5.10.0/
722     find . -type f | perl -pe's/5\.10\.0/5.10.1/g' | sort > /tmp/f1
723     cd installdir-5.10.1/
724     find . -type f | sort > /tmp/f2
725     diff -u /tmp/f[12]
726
727 =item *
728
729 Bootstrap the CPAN client on the clean install:
730
731     $ bin/perl -MCPAN -e "shell"
732
733 If you're running this on Win32 you probably also need a set of Unix
734 command-line tools available for CPAN to function correctly without
735 Perl alternatives like LWP installed. Cygwin is an obvious choice.)
736
737 =item *
738
739 Try installing a popular CPAN module that's reasonably complex and that
740 has dependencies; for example:
741
742     CPAN> install Inline
743     CPAN> quit
744
745 Check that your perl can run this:
746
747     $ bin/perl -lwe "use Inline C => q[int f() { return 42;}]; print f"
748     42
749     $
750
751 =item *
752
753 Bootstrap the CPANPLUS client on the clean install:
754
755     $ bin/cpanp
756
757 (Again, on Win32 you'll need something like Cygwin installed, but make sure
758 that you don't end up with its various F<bin/cpan*> programs being found on
759 the PATH before those of the Perl that you're trying to test.)
760
761 =item *
762
763 Install an XS module, for example:
764
765     CPAN Terminal> i DBI
766     CPAN Terminal> quit
767     $ bin/perl -MDBI -e 1
768     $
769
770 =item *
771
772 I<If you're building a SNAPSHOT, you should STOP HERE>
773
774 =item *
775
776 Check that the L<perlbug> utility works. Try the following:
777
778     $ bin/perlbug
779     ...
780     Subject: test bug report
781     Local perl administrator [yourself]: 
782     Editor [vi]: 
783     Module: 
784     Category [core]: 
785     Severity [low]: 
786     (edit report)
787     Action (Send/Display/Edit/Subject/Save to File): f
788     Name of file to save message in [perlbug.rep]: 
789     Action (Send/Display/Edit/Subject/Save to File): q
790
791 and carefully examine the output (in F<perlbug.rep]>), especially
792 the "Locally applied patches" section. If everything appears okay, then
793 delete the file, and try it again, this time actually submitting the bug
794 report. Check that it shows up, then remember to close it!
795
796 =item *
797
798 Wait for the smoke tests to catch up with the commit which this release is
799 based on (or at least the last commit of any consequence).
800
801 Then check that the smoke tests pass (particularly on Win32). If not, go
802 back and fix things.
803
804 Note that for I<BLEAD> releases this may not be practical. It takes a
805 long time for the smokers to catch up, especially the Win32
806 smokers. This is why we have a RC cycle for I<MAINT> releases, but for
807 I<BLEAD> releases sometimes the best you can do is to plead with
808 people on IRC to test stuff on their platforms, fire away, and then
809 hope for the best.
810
811 =item *
812
813 Once smoking is okay, upload it to PAUSE. This is the point of no return.
814 If anything goes wrong after this point, you will need to re-prepare
815 a new release with a new minor version or RC number.
816
817     https://pause.perl.org/
818
819 (Login, then select 'Upload a file to CPAN')
820
821 If your workstation is not connected to a high-bandwidth,
822 high-reliability connection to the Internet, you should probably use the
823 "GET URL" feature (rather than "HTTP UPLOAD") to have PAUSE retrieve the
824 new release from wherever you put it for testers to find it.  This will
825 eliminate anxious gnashing of teeth while you wait to see if your
826 15 megabyte HTTP upload successfully completes across your slow, twitchy
827 cable modem.  You can make use of your home directory on dromedary for
828 this purpose: F<http://users.perl5.git.perl.org/~USERNAME> maps to
829 F</home/USERNAME/public_html>, where F<USERNAME> is your login account
830 on dromedary.  I<Remember>: if your upload is partially successful, you
831 may need to contact a PAUSE administrator or even bump the version of perl.
832
833 Upload both the .gz and .bz2 versions of the tarball.
834
835 Wait until you receive notification emails from the PAUSE indexer
836 confirming that your uploads have been received.  IMPORTANT -- you will
837 probably get an email that indexing has failed, due to module permissions.
838 This is considered normal.
839
840 Do not proceed any further until you are sure that your tarballs are on
841 CPAN.  Check your authors directory on one of the "fast" CPAN mirrors
842 (e.g., cpan.hexten.net
843 or cpan.cpantesters.org) to confirm that your uploads have been successful.
844
845 =item *
846
847 Now that you've shipped the new perl release to PAUSE, it's
848 time to publish the tag you created earlier to the public git repo (e.g.):
849
850     $ git push origin tag v5.11.0
851
852 =item *
853
854 I<You MUST SKIP this step for SNAPSHOT or BLEAD release>
855
856 Disarm the F<patchlevel.h> change; for example,
857
858      static const char * const local_patches[] = {
859              NULL
860     -        ,"RC1"
861              PERL_GIT_UNPUSHED_COMMITS /* do not remove this line */
862
863 Be sure to commit your change:
864
865     $ git commit -m 'disarm RCnnn bump' patchlevel.h
866     $ git push origin ....
867
868
869 =item *
870
871 Mail p5p to announce your new release, with a quote you prepared earlier.
872
873 =item *
874
875 Add your quote to F<Porting/epigraphs.pod> and commit it.
876
877 =item *
878
879 I<You MUST SKIP this step for RC>
880
881 Remind the current maintainer of C<Module::CoreList> to push a new release
882 to CPAN.
883
884 =item *
885
886 I<You MUST SKIP this step for RC>
887
888 Create a new perldelta.
889
890 First, update the F<.gitignore> file in the F<pod/> folder to ignore the next
891 release's generated F<pod/perlNNNdelta.pod> file rather than this releases's
892 one which we are about to set in stone (where NNN is the perl version number
893 without the dots. i.e. 5135 for 5.13.5).
894
895 Then, move the existing F<pod/perldelta.pod> to F<pod/perlNNNdelta.pod>.
896
897 Now edit the moved delta file to change the C<NAME> from C<perldelta> to
898 C<perlNNNdelta>.
899
900 Then create a new empty perldelta.pod file for the new release; see
901 F<Porting/how_to_write_a_perldelta.pod>.
902
903 You should be able to do this by just copying in a skeleton template and
904 then doing a quick fix up of the version numbers.
905
906 Then commit the move and the new file.
907
908 For example, assuming you just released 5.10.1:
909
910     $ git mv pod/perldelta.pod pod/perl5101delta.pod
911     $ (edit pod/perl5101delta.pod to retitle)
912     $ git add pod/perl5101delta.pod
913
914     $ cp -i Porting/perldelta_template.pod pod/perldelta.pod
915     $ (edit pod/perldelta.pod)
916     $ git add pod/perldelta.pod
917     $ git commit -m 'create perldelta for 5.10.2'
918
919 Now you need to update various tables of contents, most of which can be
920 generated automatically.
921
922 Edit F<pod.lst>: add the new entry, flagged as 'd', and unflag the previous
923 entry from being 'd'; for example:
924
925     -d perl5101delta                Perl changes in version 5.10.1
926     +d perl5102delta                Perl changes in version 5.10.2
927     +  perl5101delta                Perl changes in version 5.10.1
928
929 Run C<perl pod/buildtoc --build-all> to update the F<perldelta> version in
930 the following files:
931
932     MANIFEST
933     Makefile.SH
934     pod/perl.pod
935     vms/descrip_mms.template
936     win32/Makefile
937     win32/makefile.mk
938     win32/pod.mak
939
940 Finally, commit:
941
942     $ git commit -a -m 'update TOC for perlNNNdelta'
943
944 At this point you may want  to compare the commit with a previous bump to
945 see if they look similar. See commit 2b6e134265 for an example of a
946 previous version bump.
947
948 =item *
949
950 I<You MUST SKIP this step for RC, BLEAD>
951
952 If this was the first release of a new maint series, (5.x.0 where x is
953 even), then create a new maint branch based on the commit tagged as
954 the current release and bump the version in the blead branch in git,
955 e.g. 5.12.0 to 5.13.0.
956
957 [ XXX probably lots more stuff to do, including perldelta,
958 C<lib/feature.pm> ]
959
960 Assuming you're using git 1.7.x or newer:
961
962     $ git checkout -b maint-5.12
963     $ git push origin -u maint-5.12
964
965 =item *
966
967 I<You MUST SKIP this step for RC, BLEAD>
968
969 Copy the perldelta.pod for this release into the other branches; for
970 example:
971
972     $ cp -i ../5.10.x/pod/perldelta.pod pod/perl5101delta.pod    # for example
973     $ git add pod/perl5101delta.pod
974
975 Edit F<pod.lst> to add an entry for the file, e.g.:
976
977     perl5101delta               Perl changes in version 5.10.1
978
979 Then rebuild various files:
980
981     $ perl pod/buildtoc --build-all
982
983 Finally, commit:
984
985     $ git commit -a -m 'add perlXXXdelta'
986
987 =item *
988
989 Make sure any recent F<pod/perlhist.pod> entries are copied to
990 F<perlhist.pod> on other branches; typically the RC* and final entries,
991 e.g.
992
993           5.8.9-RC1     2008-Nov-10
994           5.8.9-RC2     2008-Dec-06
995           5.8.9         2008-Dec-14
996
997 =item *
998
999 If necessary, send an email to C<perlbug-admin at perl.org> requesting
1000 that new version numbers be added to the RT fields C<Perl Version> and
1001 C<Fixed In>.
1002
1003 =item *
1004
1005 I<You MUST RETIRE to your preferred PUB, CAFE or SEASIDE VILLA for some
1006 much-needed rest and relaxation>.
1007
1008 Thanks for releasing perl!
1009
1010 =back
1011
1012 =head2 Building a release - the day after
1013
1014 =over 4
1015
1016 =item *
1017
1018 Check your author directory under L<http://www.cpan.org/authors/id/>
1019 to ensure that the tarballs are available on the website.
1020
1021 =item *
1022
1023 Check C</src> on CPAN (on a fast mirror) to ensure that links to
1024 the new tarballs have appeared.  There should be links in C</src/5.0>
1025 (which is accumulating all new versions), links in C</src> (which shows
1026 only the latest version on each branch), and an appropriate mention in
1027 C</src/README.html> (which describes the latest versions).
1028
1029 These links should appear automatically, some hours after upload.
1030 If they don't, or the C<README.html> description is inadequate,
1031 ask Ask <ask@perl.org>.
1032
1033 =item *
1034
1035 Check L<http://www.cpan.org/src/> to ensure that the C</src> updates
1036 have been correctly mirrored to the website.
1037 If they haven't, ask Ask <ask@perl.org>.
1038
1039 =item *
1040
1041 Check L<http://search.cpan.org> to see if it has indexed the distribution.
1042 It should be visible at a URL like C<http://search.cpan.org/dist/perl-5.10.1/>.
1043
1044 =item *
1045
1046 I<This step ONLY for STABLE>
1047
1048 Ask Rafael to update L<http://dev.perl.org/perl5/>.
1049
1050 =back
1051
1052 =head1 SOURCE
1053
1054 Based on
1055 http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2009-05/msg00608.html,
1056 plus a whole bunch of other sources, including private correspondence.
1057
1058 =cut
1059