It's probably not entirely clear in the spec, but it is already the
intent that version numbers work as API designators as well as module
designators. Certainly, as you speculate, if different authors want
to share an API, they can give it an "API" author that knows how to
delegate to one of the authors.
For the most part, however, I think people will use v1.2 as the API
and v1.2.3 as one particular module implementating the v1.2 API.
That was more or less why three part version numbers were invented,
after all. You'll note that we've been careful to define our matching
so that v1.2 requires an *exact* match on the specified part, so v1.2
does not match v1.3. It does, however, match any of v1.2.0, v1.2.1,
v1.2.3, up to v1.2.18446744073709551615 or so, plus any subversions
like v1.2.3.4.5.6.
Plus there's all the pattern matching, which lets you say (v1.2...)
if you really want that. Plus the fact that a v1.3 module is allowed
to advertise that it knows how to pretend to be the v1.2 interface,
though admittedly the syntax for that part isn't specced yet. In
any event, the module aliasing mechanism is expected to paper over
all those differences to the extent possible. I can say
use Penguin-1.2;
and within the rest of the *lexical* scope it aliases the short
name Penguin to whatever full name we really used, and that might
be actually be cobol:Dinosaur::Factory-42.582.17.255.255.0-DARWIN
or some such...
That probably covers most of your concerns. Improvements to the spec
always welcome...
Larry
