Update Module::Build to 0.3603

[p5sagit/p5-mst-13.2.git] / Porting / how_to_write_a_perldelta.pod

diff --git a/Porting/how_to_write_a_perldelta.pod b/Porting/how_to_write_a_perldelta.pod
index a6e9a29..5a55095 100644 (file)
--- a/Porting/how_to_write_a_perldelta.pod
+++ b/Porting/how_to_write_a_perldelta.pod
@@ -129,23 +129,28 @@ collate changes to F<ext/> and F<lib/> by module, and then summarise all
 changes to a module as a group. This can be done by partitioning directories
 within F<ext/> and F<lib/> to a number of people.
 
-B<FIXME> - this could be automated, although the two below would be easier
-to start with.
+B<FIXME> - this could be automated better
 
-Start with F<Porting/cmpVERSION.pl>
+If Module::CoreList has been updated, then F<Porting/corelist-perldelta.pl>
+will automatically print out several sections if relevent that can be
+pasted into F<perldelta>:
 
-Augment it with a flag, so that instead of reporting which modules are
-different but have the same version, report on modules which I<are> different.
-Grab the old version from the exploded tarball, and the new version from
-the git checkout, and output the line
+    * New Modules and Pragmata
+    * Pragmata Changes
+    * Updated Modules
+    * Removed Modules and Pragmata
 
-    =item *
+Each section will have stub entries following a template like this:
 
-    C<less> upgraded from version 0.01 to 0.02
+    =item C<less>
 
-That's a start.
+    Upgraded from version 0.01 to 0.02
 
-Once that's done, a more adventurous enhancement is to automate grabbing
+It does not include modules listed in F<Porting/Maintainers.pl> under
+C<_PERLLIB>, but it's a start.  Where relevent, 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,
@@ -208,7 +213,7 @@ For each file only in the newer F<MANIFEST>
 
 =over
 
-=item 1 
+=item 1
 
 Use F<git> to determine its Author
 
@@ -266,47 +271,9 @@ 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.
 
-B<FIXME> - this could be automated, at least as far as generating a first
-draft.
-
-=over
-
-=item 1
+Autogenerate this section by running something like this:
 
-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!t/.*\.t!> (and I think also for new tests in
-F<ext/DynaLoader>)
-
-=item 4
-
-Diff them
-
-=item 5
-
-For each file only in the newer F<MANIFEST>
-
-=over
-
-=item 1
-
-Grab the description line from F<MANIFEST>
-
-=item 2
-
-Write out an =item section with the filename, and description, just like
-L<http://perl5.git.perl.org/perl.git/blob/maint-5.10:/pod/perl5101delta.pod>
-
-=back
-
-=back
+ # perl newtests-perldelta.pl v5.11.1 HEAD
 
 =item Known Problems
 
@@ -335,7 +302,7 @@ The list of people to thank goes here.
 
 You can find the list of committers and authors by:
 
-  % git log v5.11.1..HEAD |grep Author | cut -d : -f 2 | cut -d \< -f 1 | sort | uniq
+  % git log v5.11.1..HEAD | perl -nlwe '$seen{$1}++ if /^Author: ([^<]*)/; END { print for sort keys %seen }'
 
 And how many files where changed by: