Following up on the comments to my blog post on CPAN::Changes and CPAN::Changes::Spec, I created a fork of the distribution on Github and implemented a first shot for the author to evaluate. I sent the pull request yesterday, so now it will be interesting see whether it will be found useful at all.
I did a lot of thinking before starting the actual coding and I was not quite satisfied with the vocabulary I was using to describe the concept. Originally I referred to the concept as impact pointer, but it is simply misleading and not particularly descriptive. So when it occurred to me that the concept was actually hints on how the reader should view the changes and release described it came to me that the obvious name should be “update hint”.
Hints are everywhere and is the term is highly popular these days. Hints are less intrusive and in this case a much better description.
Here is an example lifted from the POD.
0.03 2010−08−01 − update recommended
− Fixed serious bug in bar method
0.02 2009−07−17 − update not required
− Added more foo() tests
0.01 2009−07−16
− Initial release
I decided for two values of the hint:
- update recommended
- update not required
The first for for releases, which address serious issues/bugs like security fixes, memory leaks etc. the second for releases which are housekeeping releases, updates to tests, documentation, build scripts etc.
As you can see there is no hint for the initial release. I do not want to impose my proposal on the existing specification as such and I well let it be up to the maintainer to decide whether it should be optional and what the actual values should be, my proposal works, but it just a proof of concept and in my opinion it is a nice concept I hope will be adopted.
Please feel free to evaluate my proposal for update hints in the CPAN::Changes::Spec and let me know what you think.
jonasbn, Copenhagen/Denmark