All the Perl that's Practical to Extract and Report
use Perl Log In
Ron Savage (5224)
(email not shown publicly)
Journal of Ron Savage (5224)
Progress with Module::Metadata::Changes
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.
--Larry Wall
re: changes.conf (Score:1)
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
Re: (Score:1)
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