How to write a perldelta
This is intended as a guide for how to write a perldelta. There has never been a formal specification - the working rule is "fake up a document that looks something close to the existing perldeltas". So if it's unclear how to do something, see if it's been done before, and if the approach works there, steal it.
Template
Note there is a file Porting/perldelta_template.pod which contains a skeleton version of a perldelta.pod file, which should normally be copied in at the start of a new release.
Style
Pod is more a physical markup language, rather than a logical markup language. Despite that it has some built in conventions. Stick to them:
F<>
is for FileC<>
is for CodeL<>
is for Link
Whilst modules could also be links, usually in the context of the perldelta the reference is to code use
ing them, rather than something within their documentation.
Be consistent in how bugs are referenced. One style is
- rt.perl.org
-
perl #43010
inline, but enclose in square brackets after a sentence.[perl #43010]
. This mirrors how rt.perl.org subject lines appear. - rt.cpan.org
-
rt.cpan.org #43010
inline, but enclose in square brackets after a sentence.[rt.cpan.org #43010]
. This mirrors how rt.cpan.org subject lines appear. - ActiveState
-
http://bugs.activestate.com/show_bug.cgi?id=72443
- Debian
-
Debian bug #379463
Copy editing
Be consistent.
In a list, either make every item a note, or a full sentence. Either end every item with a full stop, or ensure that no item ends with one. regex xor regexp - choose exactly one, and stick to it.
Sections
Historically, the perldelta has consisted of a sequence of =head1
sections, usually in the same order. Un-needed sections are deleted, and if something doesn't fit nicely into the existing sections, a new more appropriate section is created.
- NAME
-
Follows this formula:
perl5104delta - what is new for perl v5.10.4
- DESCRIPTION
-
For a release on a stable branch, follows this formula:
This document describes differences between the 5.10.3 release and the 5.10.4 release.
For the start of a new stable branch, follows this formula:
This document describes differences between the 5.12.0 release and the 5.10.0 release.
Clearly this sets the scope of which changes are to be summarised in the rest of the document.
- Notice
-
There was a Notice section in perl589delta, to carry an important notice.
- Incompatible Changes
-
For a release on a stable branch, this section aspires to be
There are no changes intentionally incompatible with 5.10.3. If any exist, they are bugs and reports are welcome.
- Core Enhancements
-
New core language features go here. Summarise user-visible core language enhancements. Particularly prominent performance optimisations could go here, but most should go in the "Performance Enhancements" section.
Feature inside modules (pure-Perl and XS) go in "Modules and Pragmata"
- New Platforms
-
List any platforms that this version of perl compiles on, that previous versions did not. These will either be enabled by new files in the hints/ directories, or new subdirectories and README files at the top level of the source tree.
- Modules and Pragmata
-
All changes to installed files in ext/ and lib/ go here, in a list ordered by distribution name. Minimally it should be the module version, but it's more useful to the end user to give a paragraph's summary of the module's changes. In an ideal world, dual-life modules would have a Changes file that could be cribbed.
Whilst this section could be built by incrementally working through change descriptions applying to files, this is prone to error. It's better to collate changes to ext/ and lib/ by module, and then summarise all changes to a module as a group. This can be done by partitioning directories within ext/ and lib/ to a number of people.
FIXME - this could be automated better
If Module::CoreList has been updated, then Porting/corelist-perldelta.pl will automatically print out several sections if relevant that can be pasted into perldelta:
* New Modules and Pragmata * Pragmata Changes * Updated Modules * Removed Modules and Pragmata
Each section will have stub entries following a template like this:
=item C<less> Upgraded from version 0.01 to 0.02
It does not include modules listed in Porting/Maintainers.pl under
_PERLLIB
, but it's a start. Where relevant, a summary of changes can be added by hand.A more adventurous enhancement would be to automate grabbing the changelogs for dual lived modules. For each of them, grab the relevant changes files from CPAN for the old and new versions, and if the old one is a strict subset of the new one, splice the extra lines right into the output, as a basis for summarising.
(And if not, experiment with using git to get the relevant part of changelog for the particular file in core)
These could also be enhanced further by using a Pod parser module to produce a parse tree of perl${whatever}delta.pod, and splicing in the updates correctly without throwing existing entries away.
If you think that's nuts, take a look at what pod/buildtoc already does to splice into existing Makefiles on various platforms:
http://perl5.git.perl.org/perl.git/blob/blead:/pod/buildtoc#l498
Perl is this really powerful language for text manipulation. And fun to play with. We need to get that message out. :-)
- Utility Changes
-
Changes to installed programs such as perlbug and xsubpp go here. Most of these are built within the directories utils and x2p.
- New Documentation
-
Changes which create new files in pod/ go here.
FIXME - this could be automated, at least as far as generating a first draft.
Start with a clean exploded tarball of the previous release, and a clean checkout of the branch in question
Take the MANIFEST file of each
Search for lines matching
m!^pod/.*\.pod!
Diff them
Explode if anyone deleted documentation. [No idea what the policy on that is yet]
For each file only in the newer MANIFEST
Use git to determine its Author
Open the pod file itself
Grab the description section
Write out a block of text starting roughly
L<perlfoo>, by A. U. Thor, provides @description
- Changes to Existing Documentation
-
Changes which significantly change existing files in pod/ go here. Any changes to pod/perldiag.pod should go in "New or Changed Diagnostics".
- Performance Enhancements
-
Changes which enhance performance without changing behaviour go here. There may well be none in a stable release.
- Installation and Configuration Improvements
-
Changes to Configure, installperl, installman, and analogous tools go here.
- Selected Bug Fixes
-
Important bug fixes in the core language are summarised here. Bug fixes in files in ext/ and lib/ are best summarised in "Modules and Pragmata".
- New or Changed Diagnostics
-
New or changed warnings emitted by the core's
C
code go here. - Changed Internals
-
Changes which affect the interface available to
XS
code go here. - New Tests
-
Changes which create new files in t/ go here. Changes to existing files in t/ aren't worth summarising, although the bugs that they represent may be.
Autogenerate this section by running something like this:
# perl newtests-perldelta.pl v5.11.1 HEAD
- Known Problems
-
Descriptions of platform agnostic bugs we know we can't fix go here. Any tests that had to be
TODO
ed for the release would be noted here, unless they were specific to a particular platform (see below). - Deprecations
-
Add any new known deprecations here.
- Platform Specific Notes
-
Any changes specific to a particular platform. VMS and Win32 are the usual stars here. It's probably best to group changes under the same section layout as the main perldelta.
- Obituary
-
If any significant core contributor has died, we've added a short obituary here.
- Acknowledgements
-
Generate this with:
perl Porting/acknowledgements.pl v5.15.0..HEAD
- Reporting Bugs
-
This doesn't usually need to be changed from the previous perldelta.
- SEE ALSO
-
This doesn't usually need to be changed from the previous perldelta.