AndrevanTonder <andre at het.brown.edu> writes:
> Suggested alternative #3:
> -------------------------
>
> Give <version reference> the same syntax as <version>. A match occurs if
> <version reference> matches <version> up to the number of elements provided
> in <version reference>.
>
> In other words, (rrs (6 2)) would match versions (6 2), (6 2 3), etc.
> [...]
> For example, the current specification allows one to specify that a client
> program will work only with version (6 2) and not with version (6 2 3) of some
> library. However, if this is the case, assigning version (6 2 3) to a library
> that is not backward-compatible is clearly wrong, and providing the ability to
> specify such a constraint will only encourage such errors.
As much as I'd like this, my experience with Python, Perl and the like,
and the design of the library system make me hesitate: The problem is
that one person's compatible upgrade is another person's incompatible
change. Ideally, we'd have only three components to each version
number: major, minor, and "patch level". The patch level gets bumped
when bugs get fixed, minor gets bumped when things are added to the
interface, and major gets bumped when incompatible changes are made.
In the real world, I've often seen people work around bugs, effectively
producing code that depends on their specific nature. (I know they
shouldn't, relying only on the interface. We don't even have a serious
notion of "interface".) Fixing the bug breaks their code. So,
patch-level changes are really often incompatible changes. Minor gets
bumped when old keywords acquire new syntatic cases---that's OK, I
think. It also gets bumped when old procedures work on more inputs than
before. Mostly OK, but can cause problems when clients rely on
exceptions for these cases. Minor also gets bumped when new exports are
added, which may clash with other libraries. Bad.
I'm still oversimplifying a bit, but you get the drift, I hope. That
leaves conservative extensions to the syntax as the only mostly-safe way
to do a non-major upgrade to a library. I predict it will be
comparatively rare that this is the *only* kind of change in an upgrade.
(I predict this will remain to be true even as you factor in extending
the domains of existing procedures.)
This is why the whole versioning thing is comparatively rich---people
won't get their version references right on the first try, but they'll
evolve. And, if they look funny, that's a sign the library author has
probably done something wrong.
--
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla
Received on Thu Jun 21 2007 - 07:36:23 UTC