develooper Front page | perl.perl5.porters | Postings from October 2013

[perl #116475] automate perldelta "new modules" section

Thread Next
Abir Viqar via RT
October 7, 2013 06:30
[perl #116475] automate perldelta "new modules" section
Message ID:
The patches attached are what I have attempted so far.

Patches 1-6 are mostly improvements to's check
mode that are unrelated to the task at hand, but were helpful in
observing past perldelta.

Patch 7 includes fixes for the determination of changed modules that
takes into account the mapping between distribution and key module based
on how their changes have been listed in past perldelta. With
this, the only distributions that are currently unaccounted for are
podlater, libnet, and Win32. However, the determination of removed
modules still includes too many false positives to be useful.

Patch 9 is my initial attempt at being able to update an existing
perldelta file by adding unlisted modules and updating the version
number of listed modules if they differ from Module::CoreList. I used
the non-core Pod::Elemental for pod manipulation. The core pod parsing
modules don't seem to allow easy serialization back to pod, especially
without including whitespace differences. Is the use of Pod::Elemental
acceptable, and if not, what alternate approach should I take?

I have not included documentation changes pending comments to my patches.
On Sun Sep 15 11:30:29 2013, shay wrote:
> I think a program to ensure that each module that has been upgraded
> since the previous release is listed in perldelta would be useful. (At
> the moment (as RM for this month and last) I keep an eye on commits each
> day, and also manually diff the previous release with the current
> release-to-be just before release to check that nothing has been missed.)
> However, there is a limit to what can be automated. Certainly the
> "L<Module> has been upgraded from version X to Y." item could be added
> if missing, but writing the detail which follows that line, describing
> what has been changed, is really a manual process. Not every module has
> a Changes file that could be scanned for a list of changes, and even
> where such a file exists I do not deem it appropriate to list every
> single change in the perldelta file: that would be too much duplication.
> Instead, I try to summarize what the major changes are, and sometimes
> refer the reader to the Changes file for more detail if necessary. This
> summarizing process will always be a manual task since it requires human
> judgement.
> The program should be tolerant of upgrade entries which already exist
> (i.e. it must not go adding duplicate sections for a given module)
> because I personally would still be inclined to perform this process
> incrementally through the month to avoid having the whole of that
> necessarily manual part still to do at release time.
> So really I think the program just needs to add
>     =item *
>     L<Module> has been upgraded from version X to Y.
>     XXX TODO
> for each upgraded Module that isn't already listed.
> Take care over the name of the Module. The directory names in cpan/ and
> dist/ are mostly (if not all?) the names of CPAN *distributions* rather
> than *modules*, but perldelta generally lists a single "key" module name
> for each one since this is more meaningful to users of the perl core,
> who may not even be aware of the dual-lived nature of some modules.
> Having said that, if a distribution contains very many modules that have
> been upgraded then it might be better to refer to a collection of
> modules by their distribution name instead. (Thus, if Scalar-List-Utils
> is upgraded, then it is probably best to mention each module
> (Scalar::Util and List::Util) separately, especially if only one has
> been changed. But if IO-Compress is upgraded and lots of modules in it
> have been changed, perhaps with similar changes in each file, then it
> would be excessive to list them all separately.)
> Thank you for your interest in helping to automate parts of the release
> process! :-)

via perlbug:  queue: perl5 status: open

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About