AndrevanTonder <andre_at_het.brown.edu> writes:
> One might be able to simplify this further. There is a natural
> ordering on version number sequences as a whole, and it seems natural
> to have the >=, <= express this ordering.
I agree that it would be simpler. However, I think this will tip the
scale a bit in favor of version number requirements that don't pass
the test of time:
> (>= (3 2))
>
> which would match (3 4), (3 2 1), (4 1) ...
This would be the easiest version spec to write if you were, while
developing your client, looking at version (3 2), and you expect
things to only "get better" with time. However, a widespread
convention is to use the most significant version number component to
indicate "major changes", so that versions (4 ...) and beyond will be
incompatible with versions (3 ...). So I personally prefer requiring
people to write down explicitly that (4 ...) and beyond is OK.
I think version specs that don't age well will be written regardless.
But a little guidance would be nice.
> By the way, with neither your proposal nor mine do I think it is
> possible to express a match on anything later than (3 2). In other
> words, when (3 2) should not match but (3 2 0 1), (3 2 0 0 0 0 1),
> ... should. Do you think this is important?
I'm not sure. This is all pretty gooey territory. But including <
and > would fix the problem, right?
--
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla
Received on Mon Dec 11 2006 - 07:22:16 UTC