In general I'm not opposed to the idea of this module. The included 'changes' script is also pretty cool (which I'm trying to recreate, for CPAN::Changes).
Just pointing out that I believe this module has not really "caught on" among the CPAN community. What has, is, CPAN::Changes which is followed by many authors and even employed on MetaCPAN.
Not even working. I don't see changes tool after installed.
metacpan.org/pod/distribution/Module-... is the doc I follow.
The Changes file has traditionally been a *human*-readable file. The last thing somebody expects when reading a history file is to see YAML. Yuck!
If you want to have a machine-readable change history, use a different filename like "Changes.yml". And generate a human-readable file from that.
A machine-readable Changes file won't solve the problems that it's intended to. There's no guarantee that a change marked as "security fix" or "bug fix" won't break your system anyway by introducing new bugs or fixing ones that you thought were features, nor is there a guarantee that the author tagged changes correctly. And if a security fix is mixed in with API changes, then you can't separate the two.
If you're so concerned about updates breaking your system, then you're a fool to rely on automated tools in Perl. Read the Changes file, look at version diffs, test on a different server before upgrading. (This is what a responsible sysadmin should do anyway.)
Or better yet, don't upgrade if you don't have to.
I'm not sure why the reviews for this module are so negative. First of all, there is no requirement that you install, require, or use this module to have a machine-readable Changes file. You just write it, and this module processes it on the toolchain end.
The possibilities a machine-readable Changes file opens up are enormous. Have you ever installed YAML? You'll notice that it warns you that it is incompatible above 0.60 *every time you install it*. If the toolchain was aware of tags in the Changes file, then CPAN.pm could warn you, and you could set an "I don't care option". Or, you could set a "log whenever I upgrade something marked as incompatible". Then when your app breaks, you can review the log and see which module changed something. Or, you could simply refuse to install that module.
Finally, I had no trouble installing this module. "cpanp install Module::Changes" and there it was. I'm not sure what was wrong with the other reviewers' machines, but the problem is probably on their end.
Anyway, the other reviewers seem pretty clueless (about this module, and in general), so I would take their reviews with a very large grain of salt.
2 hidden unhelpful reviews