Check out Version::Split http://www.fergaldaly.com/computer/Version-Split/
which does what I'm talking about. It's a terrible name, any better ones? It answers many of the questions you asked, the others are below. On Wed, Jan 21, 2004 at 08:41:35PM -0600, david nicol wrote: > Q: was this suggestion made as a perl6 RFC and if so what did Larry > think of it? Nope, it's just something that's been brewing in my head for a while. I found this http://dev.perl.org/perl6/rfc/78.html which tries to address the problem with <, > etc but doesn't try to distinguish between revision and interface which is key. > 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. Never noticed the VERSION method before now so I didn't even think of it. Thanks for pointing it out! It seems to do the trick nicely in terms of preventing bad versions being used and allowing good versions. However the other important place for version checking is in Build.PL, Makefile.PL and CPAN/CPANPLUS and they tend to take a greater than or equal to type of approach. They may need to be adapted to work with custom VERSION() methods. > 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. You could make your VERSION() method do all the work for you there if you really want to. > 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. Sounds interesting but might be more part of the KWALITEE project. Not sure if it should enforce it or just point out when you break it and maybe CPAN.pm could ignore it too or shout loudly about it when you download it. > 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) You would need to split up your test suites into an interface test suite and a release test suite. The interface one would probably have to live separately. All in the future... One cool thing is that some modules already have lots of interface only tests that already live outside the module, namely the tests in modules that use it. So for instance if A requires B 1.2 and I upload a new B 1.2 and suddenly A's tests start failing then CPAN(TS) should tell A's author and myself about it and we can figure it out. > 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. Something like that would be cool, F
