On Wed, 2004-01-21 at 04:32, Fergal Daly wrote:
> A better (IMHO) alternative is to make the interface part of the version
> number as important as the name. This is equivalent to including it in the
> name except you don't lose information like you do when you just glue a
> number on the end of the name. You also get to use '.'s in the version
> number because you're not try to make a valid Perl module name. Then CPAN
> and other tools could understand the relationship between different versions
> of modules.
>
> Unfortunately, this is the bit I think will never happen, I don't think it
> would be possible to convince people that this is worthwhile, possibly
> because it's not worthwhile at this late stage.
Q: was this suggestion made as a perl6 RFC and if so what did Larry
think of it?
Q2: Do you have a really clear idea of what split interface/version
numbers would look like and is it light enough to try to get it
into perl 5.9.1 ? (act fast)
Could the situation be resolved by insisting that the first number
in a version string is the interface version and following numbers
are revision numbers, and rewriting C<require> in some way to
respect that? For instance, require could take a regex as an argument
and when that happens the version would have to match the regex,
and the same with the VERSION element of C<use>
If the VERSION argument is present between Module
and LIST, then the "use" will call the VERSION
method in class Module with the given version as
an argument. The default VERSION method, inherÂ
ited from the UNIVERSAL class, croaks if the given
version is larger than the value of the variable
"$Module::VERSION".
So we're talking about altering "the default VERSION method" to
recognize something other than a version string, that would trigger
a different case. Such as, the major number has to match and the
minor number has to be greater, or a PROVIDES method which defaults to
the @{"$Module::PROVIDES"} array must include a version number with
the same major number as the one we want.
Or maybe we're talking about enlightened new versions of modules
that present old interfaces when provided an old version number. This
is IMO a non-starter, since it would require a lot of work that
will not seem necessary by the people who would have to do the work.
Or maybe we're talking about adding a bureaucratic layer to CPAN so
it won't accept new versions of modules under the same name unless
the new version passes the test suite from the old version, for modules
on a restricted list that your module gets on once enough people rely on
your module.
The last suggestion would enforce interface compatability, after a
fashion.
It would need to be documented thoroughly so people don't go including
test cases for things known to be broken in their modules, that verify
that the modules are broken in the way that the modules are broken. (I
have done this; DirDB 0.0.6 fails tests in DirDB 0.0.5 concerning
croaking on unhandleable data types)
Compliance might be part of a "standard quality check" before a module
with a positive major version number is accepted; or CPAN might enforce
quality ratings, which would be enforced to be nondecreasing, for a
given module name.
So if a module has a PRODUCTION quality rating, that means that the
interface is guaranteed to remain stable into the future, under the
given name.
And that tests for things that are broken and you mean to fix in the
future would have to be marked as such in the tests.pl.
:)
David Nicol
--
david nicol
"In order to understand what another person is saying, you must assume that it
is true and try to imagine what it could be true of." (George Miller; 1980.)
