On 3/8/07, Smylers wrote:
In Perl 5 if you rely on a feature (or bugfix) from a particular
version of a module you can specify that version and the code will
continue to work with future versions -- which is a reasonably
pragmatic approach, effectively saying "until proven otherwise I'll
presume that any future releases of this module won't break this
functionality".
I think that looking at versions from the perspective of the person
using the module is the wrong way around: as you point out, when I
write a program, I have no way of knowing whether future versions of
some module will continue to work (I just assume they do and hope for
the best) -- however, the author of the module should know! So it
should be the *modules* that specify compatible version ranges, not
my program.
And if you are using my program, I likely have no knowledge or
control of what versions of what modules you might be running.
Instead, I ought to specify what version of the module I wrote my
code against (that's one thing I can know for sure); future versions
of the module should then themselves specify which previous versions
they are compatible with.
module Foo:<2.3.4 cpan:JSMITH>
does versions(0.8.0..1.2.2, 1.2.4..2.3.4);
In this example, Foo has been pretty compatible since v0.8, but it
skips v1.2.3, let's say because that version had a bug so it wasn't
really compatible (even though it probably said it was).
My program would say (coining "used" for the sake of example):
used Foo:<2.0.0>;
to indicate the exact version of the module I used to write my code.
Then it doesn't matter whether that exact version is available as
long as there is some module that advertises itself as doing
Foo:<2.0.0>. (As determined by the modules, or by Perl, or by the
Parrot Library Management System.)
Of course, I would still need to be able to specify details such as
"but don't use Foo:<1.2.3> even though it claims to be compatible,
because really I know it's buggy".
This would also allow for modules that are compatible not only with
other versions of themselves, but also with other modules of a
different name. (If your module provides the Foo interface, why not
just name it Foo -- especially since you can choose an authority to
carve out your own space in the Foo universe? You should, of course,
unless your module also is compatible with module Bar. It can't have
two names, but it can advertise itself as being compatible with two
or more other modules.)
-David
