On Tue, Jan 20, 2004 at 12:17:51PM +0100, A. Pagaltzis wrote:
> Perl does not provide for keeping around same-named modules that
> differ in some other way.
That's not true. There are many modules where for example version 1.xx has
one interface and 2.xx has a different interface and then 2.xx where xx < 37
is a slightly different to 2.xx for xx >= 37 and so on.
Unfortunately version number in Perl/CPAN (and for that matter most other
versioning systems) aren't used as usefully as they could be.
Each module has a behaviour/interface version and each of these has a
revision. What most people care about when they say "you need version x.y.z"
is the behaviour/interface version. They're saying you need the version that
does this, that and the other. They almost never care about the revision,
you should just use the latest revision of version x.y.z on the assumption
that it is the one that actually comes closest to implementing the
documented behaviour with the fewest bugs.
It's possible to represent this information in string form quite easily, for
example $IfaceVersion_$Rev would do the job, a typical instance might look
like
2.3.4_57
2.3.4_58
2.3.5_1
which would mean that 2.3.4_58 "is better (less buggy) than but has the same
intention as" 2.3.4_57. 2.3.5_1 does something slightly different from
2.3.4_xx and is not suitable as an upgrade without careful consideration by
the programmer. Unfortunately, this is not how things work at the moment
Perl tools currently think 2.3.5 is higher than 2.3.4 and may think it's ok
to use 2.3.5 where 2.3.4 was requested with possible nasty results.
What this all has to do with names is that in the scheme above, you can
easily stick an author into the version to make 2.3.5-JBLOGGS_33. No need to
extend the module namespace with author prefixes.
Not that this would ever be agreed upon, the old way is ingrained. Modules
will continue to do for example
PREREQ_PM => { Parse::RecDescent => 1.80 }
then fall over because 1.90 satisfies this requirement but is not actually
compatible,
F
