Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer

Should Changes file be Test'd

by gam3 (Curate)
on Apr 17, 2008 at 15:33 UTC ( #681197=perlquestion: print w/replies, xml ) Need Help??
gam3 has asked for the wisdom of the Perl Monks concerning the following question:

I am thinking of writing a Test::CheckChanges package.

This package would check that that there is a Changes file and that that file has a standard (be it loose) format, and that the version of the latest entry matches the version of the current release.

I am looking for the thoughts of other PerlMonks on this project.


-- gam3
A picture is worth a thousand words, but takes 200K.

Replies are listed 'Best First'.
Re: Should Changes file be Test'd
by elmex (Friar) on Apr 17, 2008 at 15:58 UTC

    There is already something like that for the CPANTS/kwalitee site, it has a test that checks whether there is a changelog present in the distribution: Module::CPANTS::Analyse::Kwalitee::Files.

    Aside from that: What would be the benefit to test whether the changes file has a special syntax? The module would have to handle multiple styles of changes files I guess, as there is are lots of variations of 'Changes' files out there. Some even name them 'HISTORY' or 'WhatsNew' or what not...

    At least I wouldn't find such a test that useful, as I'm not that picky about the format of a changelog. As long as the most important changes are documented somewhere and somehow. So I guess the most important thing is, that the Changes file is present.

    But such a test would of course only benefit the maintainer/author of a module, and shouldn't be in the distribution IMO.

    That is of course just my two cents, if YOU find such a module useful and would use it, then I don't see any argument against such a module.

Re: Should Changes file be Test'd
by Your Mother (Chancellor) on Apr 17, 2008 at 16:04 UTC

    Sounds tricky but it could be a nice sanity check for making distributions when you're focused on things besides the README and Changes. I've seen two CPAN packages lately that had things like "Not released yet" as the version number in the Changes file. Not terribly important though since nothing relies on the Changes file but humans and humans who can't parse that sort of typo/omission are where the real repairs should happen. Uh, I mean... we're all beautiful snowflakes. That's what I meant.

Re: Should Changes file be Test'd
by mirod (Canon) on Apr 17, 2008 at 17:09 UTC

    Did you look at this post: Simplified parseable Changes: draft 2, that would give you a starting format for a change file.

    BTW, I am not sure I really like the format, and I am pretty sure I won't convert old change files to it, but if this format ends up being widely used, then I will gladly adopt it for future modules.

Force Changes creation...
by mlawren (Sexton) on Apr 18, 2008 at 08:57 UTC

    What I would find more useful is a plugin/extension to the "make dist/distdir" target for Module::Install/Build.PL/other which automatically extracted the log from whatever revision control system is in place. I am constantly doing "cg-log > Changes" and yes, I have forgotten to do that for releases as well.

    If no repository is found and no entry for the current VERSION is found in the Changelog then the target could prompt for an entry.

Re: Should Changes file be Test'd
by moritz (Cardinal) on Apr 18, 2008 at 10:12 UTC
    To test something, you have to test it against something. Like, a specification.

    Currently there is none, so I see no point in testing. But IMHO that should change.

    I find this lack of computer readable meta information on CPAN quite sad, because it prevents many useful applications (for example I'd like to write a CPAN mirror that automatically builds debian packages from CPAN packages, but currently there's not even an consensus how dependencies on non-perl libraries should be declared).

    So maybe the right thing to do is to specify an option in META.yml which specifies the Changelog format, so if a package includes that option the test is run, if not you should only test that the file exists and is not empty.

Re: Should Changes file be Test'd
by mscharrer (Hermit) on Apr 18, 2008 at 09:55 UTC
    One idea would be to identify which sub function have changed and to check if this changes are mentioned in the Changes file, i.e. by checking if the sub names are mentioned.

    I think the GNU diff can show the names of changed function for C code. Maybe there is a way to do similar thing for Perl code.

    PS: This remains me on the Pod::Coverage package which checks if there is documentation for every sub function.

Re: Should Changes file be Test'd
by arc_of_descent (Hermit) on Apr 18, 2008 at 06:35 UTC

    Checking for the existence of the Changes file is available in Test::Kwalitee via the have_changelog test. I'm not too sure about the check for format though.


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://681197]
Approved by ikegami
Front-paged by ikegami
and a soft breeze sighs...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (3)
As of 2017-09-23 20:18 GMT
Find Nodes?
    Voting Booth?
    During the recent solar eclipse, I:

    Results (273 votes). Check out past polls.