On 13-12-20 01:25 PM, Karen Etheridge wrote:
I don't think it's wise to assume any connection between a module's version
and its stability, unless the documentation explicitly says so.
This touches a side-thought that has been on my mind for a little while,
and I'm curious to see what other authors think about it.
I try to adhere to semantic versioning for my modules. So it means that
when I jump from 1.x to 2.y, something in the API is
backward-incompatible. In the Build.PL, it would be fairly easy to do
# massively pseudo-codish
my $old_version = eval "use Foo; Foo->VERSION";
if ( $old_version and $new_version - $old_version > 1 ) {
die q{
new version of Foo contains non-backward
compatible changes. Review the changelog, and if that's
really what you want, do
$ FOO_MAJOR_UPDATE=1 cpanm ...
} unless $ENV{FOO_MAJOR_UPDATE};
}
Although that seems like a neat way to prevent updates to break things
left and right, I have the feeling it would result in a new depth of
dependency hell for end-users (if you are a casual user and that kind of
warning pops up for modules thirty-dependency deep in your module chain,
I expect lots of potential cursing and swearing to ensue).
Perhaps a saner middle-ground could be of introducing a new environment
variable CPAN_NO_MAJOR_JUMP. That way developers who care can enable it
and get the appropriate warnings when they do their cpanm/pinto/whatev
dance, while leaving the current default toolchain behavior untouched.
So, yeah, what does the author gestalt thinks of the concept? Has
potential? Over-engineering not really needed? Need more egg nog? :-)
Joy,
`/anick
