File: how_to_write_a_perldelta.pod

package info (click to toggle)
perl 5.24.1-3+deb9u5
  • links: PTS, VCS
  • area: main
  • in suites: stretch
  • size: 103,716 kB
  • sloc: perl: 559,611; ansic: 293,886; sh: 67,316; pascal: 7,632; cpp: 3,895; makefile: 2,436; xml: 2,410; yacc: 989; sed: 6; lisp: 1
file content (305 lines) | stat: -rw-r--r-- 8,007 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
=head1 NAME

how_to_write_a_perldelta - How to write a perldelta

=head2 Description

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.

=head2 Template

Note there is a file F<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.

=head2 Style

Pod is more a physical markup language, rather than a logical markup language.
Despite that it has some built in conventions. B<Stick to them>:

=over 4

=item * C<FE<lt>E<gt>> is for File

=item * C<CE<lt>E<gt>> is for Code

=item * C<LE<lt>E<gt>> is for Link

=back

Whilst modules could also be links, usually in the context of the perldelta
the reference is to code C<use>ing them, rather than something within their
documentation.

Be consistent in how bugs are referenced. One style is

=over 4

=item rt.perl.org

C<perl #43010> inline, but enclose in square brackets after a sentence.
C<[perl #43010]>.  This mirrors how rt.perl.org subject lines appear.

=item rt.cpan.org

C<rt.cpan.org #43010> inline, but enclose in square brackets after a sentence.
C<[rt.cpan.org #43010]>.  This mirrors how rt.cpan.org subject lines appear.

=item ActiveState

C<http://bugs.activestate.com/show_bug.cgi?id=72443>

=item Debian

C<Debian bug #379463>

=back

=head2 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. I<regex>
B<xor> I<regexp> - choose exactly one, and stick to it.

=head2 Sections

Historically, the perldelta has consisted of a sequence of C<=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.

=over

=item NAME

Follows this formula:

    perl5104delta - what is new for perl v5.10.4

=item 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.

=item Notice

There was a I<Notice> section in L<perl589delta>, to carry an important
notice.

=item 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.

=item 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 L</Performance Enhancements> section.

Feature inside modules (pure-Perl and XS) go in L</Modules and Pragmata>

=item 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 F<hints/>
directories, or new subdirectories and F<README> files at the top level of the
source tree.

=item Modules and Pragmata

All changes to installed files in F<cpan/>, F<dist/>, F<ext/> and F<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 F<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 by module, and then summarise all changes to a module as a
group.

If Module::CoreList has been updated, then F<Porting/corelist-perldelta.pl>
will automatically update two sections in F<perldelta>:

    * New Modules and Pragmata
    * Updated Modules and Pragmata

(Currently, it does not update the Removed Modules and Pragmata section.)

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 F<Porting/Maintainers.pl> under
C<_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, use the extra lines as a basis for summarising.

(And if not, experiment with using F<git> to get the relevant part of changelog
for the particular file in core.)

=item Utility Changes

Changes to installed programs such as F<perlbug> and F<xsubpp> go here. Most
of these are built within the directory F<utils>.

=item New Documentation

Changes which create B<new> files in F<pod/> go here.

B<FIXME> - this could be automated, at least as far as generating a first
draft.

=over

=item 1

Start with a clean exploded tarball of the previous release, and a clean
checkout of the branch in question

=item 2

Take the F<MANIFEST> file of each

=item 3

Search for lines matching C<m!^pod/.*\.pod!>

=item 4

Diff them

=item 5

Explode if anyone deleted documentation. [No idea what the policy on that is
yet]

=item 6

For each file only in the newer F<MANIFEST>

=over

=item 1

Use F<git> to determine its Author

=item 2

Open the pod file itself

=item 3

Grab the description section

=item 4

Write out a block of text starting roughly

    L<perlfoo>, by A. U. Thor, provides @description

=back

=back

=item Changes to Existing Documentation

Changes which significantly change existing files in F<pod/> go here.
Any changes to F<pod/perldiag.pod> should go in
L</New or Changed Diagnostics>.

=item Performance Enhancements

Changes which enhance performance without changing behaviour go here. There
may well be none in a stable release.

=item Installation and Configuration Improvements

Changes to F<Configure>, F<installperl>, F<installman>, and analogous tools
go here.

=item Selected Bug Fixes

Important bug fixes in the core language are summarised here.
Bug fixes in files in F<ext/> and F<lib/> are best summarised in
L</Modules and Pragmata>.

=item New or Changed Diagnostics

New or changed warnings emitted by the core's C<C> code go here.

=item Changed Internals

Changes which affect the interface available to C<XS> code go here.

=item New Tests

Changes which create B<new> files in F<t/> go here. Changes to existing files
in F<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

=item Known Problems

Descriptions of platform agnostic bugs we know we can't fix go here. Any
tests that had to be C<TODO>ed for the release would be noted here, unless
they were specific to a particular platform (see below).

=item Deprecations

Add any new known deprecations here.

=item 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.

=item Obituary

If any significant core contributor has died, we've added a short obituary
here.

=item Acknowledgements

Generate this with:

  perl Porting/acknowledgements.pl v5.15.0..HEAD

=item Reporting Bugs

This doesn't usually need to be changed from the previous perldelta.

=item SEE ALSO

This doesn't usually need to be changed from the previous perldelta.

=back