`/anick -

This would be dependency hell. I think a prominent warning (as suggested by
Aristotle) would be much better. Whether we should have this sort of
environment variable around is a good question. How would we develop an
awareness and use of this variable?

David


On Sun, Dec 22, 2013 at 11:32 AM, Yanick Champoux
<yan...@babyl.dyndns.org>wrote:

> 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
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan

Reply via email to