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.

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.

Did you look at this use.perl.org 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.

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.

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.

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.

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.