Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ron Savage (5224)

Ron Savage
  (email not shown publicly)

Journal of Ron Savage (5224)

Monday May 05, 2008
01:19 AM

Progress with Module::Metadata::Changes

[ #36327 ]

You'll be delighted to know that after an investigation I've abandoned the idea of using YAML, although I suspect the number of people who are relieved is far greater than the number of people who are surprised.

I've had a look at 31 config file parsers, and I think I'll go with Config::IniFiles, since it allows here docs, which are suitable for the extended comments we see in CHANGES files.

I'll standardize on the file name Changes.conf, which after an incomplete analysis (using Archive::Extract), I can see is not in use:

Frequencies:
CHANGE.LOG => 3.
CHANGELIST => 1.
CHANGELOG => 112.
CHANGES => 792.
CHANGES-1.0 => 1.
CHANGES-2.20 => 1.
CHANGES-2.22 => 1.
CHANGES-2.23 => 1.
CHANGES-3.00 => 3.
CHANGES-cp1251.txt => 1.
CHANGES.OLD => 1.
CHANGES.TXT => 1.
CHANGES.etext => 1.
CHANGES.html => 2.
CHANGES.mogilefsd => 1.
CHANGES.mogstored => 1.
CHANGES.old => 1.
CHANGES.pod => 3.
CHANGES.txt => 14.
CHANGE_LOG => 1.
Change.log => 3.
ChangeLog => 752.
ChangeLog-1-00-02 => 1.
ChangeLog-Perl-1-00-01 => 1.
ChangeLog.0 => 2.
ChangeLog.1 => 3.
ChangeLog.1x => 1.
ChangeLog.2 => 1.
ChangeLog.20 => 1.
ChangeLog.21 => 1.
ChangeLog.3 => 1.
ChangeLog.4 => 1.
ChangeLog.5 => 1.
ChangeLog.6 => 1.
ChangeLog.CVS => 1.
ChangeLog.CVS.delta => 1.
ChangeLog.SPOON => 2.
ChangeLog.d => 1.
ChangeLog.detailed => 2.
ChangeLog.old => 1.
ChangeLog.owen => 2.
ChangeLog.svn => 2.
ChangeLog.txt => 1.
ChangeLog.xml => 5.
ChangeLog~ => 1.
Changelog => 52.
Changes => 11503.
Changes-2.64 => 1.
Changes-darcs => 1.
Changes.0.46 => 1.
Changes.1 => 1.
Changes.Checker => 1.
Changes.DOM => 1.
Changes.XQL => 1.
Changes.bak => 1.
Changes.html => 3.
Changes.i18n => 1.
Changes.ja => 1.
Changes.old => 3.
Changes.pod => 10.
Changes.src => 2.
Changes.ttl => 4.
Changes.txt => 62.
Changes.ver0X => 1.
Changes.yml => 2.
Changes1.6 => 1.
Changes~ => 5.
changelog => 2.
changelog.html => 1.
changelog.txt => 1.
changes => 4.
changes.dat => 1.
changes.pod => 1.
changes.txt => 2.
changesrus.txt => 1.
changesrus_koi8.txt => 1.

As for the format, I'm thinking of:

[Killer::App]
1.02=2008-01-25T10:08:00
1.01=2008-01-25T10:08:00
1.00=2007-07-27T18:30:45

so the version numbers can be sorted by date to get the latest version, followed by one section per version:

[1.02]
lapsang suchong...

[1.01]
Lorem ipsum...

etc.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • .conf seems like a bad choice. The summary of changes is not configuration. The .conf extension does not tell you how the file is formatted, but rather what it is for. A changelog is not for configuration. Why not ChangeLog.ini or something like that? The filename makes the content purpose clear and the extension makes the type clear.

    I don't see the value in the top-level section for version-date pairs. Presumably the file will always be written out to place the sections in a useful order, and anyone
    --
    rjbs
    • Hmmm, you make some good points.

      I would argue that a change log supplies config info pertaining to each version, so the choice is not that bad. But I'll certainly reconsider. After all, nothing is cast in Perl-based stone just yet.

      I would like an extension which definitively indicated the format, a la yml and xml, but without the format being known, that's not so easy.

      Changelog.ini is reasonable. That sort of feedback is the point of posting in the first place.

      The date can easily be a per-section entry, and