[r6rs-discuss] [Formal] Version reference syntax is overly complex.

From: Shiro Kawai <shiro>
Date: Thu, 21 Jun 2007 09:36:30 -1000 (HST)

From: Michael Sperber <sperber at informatik.uni-tuebingen.de>
Subject: Re: [r6rs-discuss] [Formal] Version reference syntax is overly complex.
Date: Thu, 21 Jun 2007 13:36:23 +0200

> 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.

An excellent summary, and this is exactly why I think r5.94rs
version reference won't work well. Even library foo releases
version 2.3.1 that fixes number of bugs in 2.3, you cannot
expect everyone to upgrade to foo-2.3.1 immediately; sometimes
it take months or even a few years until migration is done,
especially when lots of code depends on foo. If your library
breaks because of the subtle incompatibility between foo-2.3
and foo-2.3.1, how you want to maintain your library?

You may release both yourlib-1.3 which requires foo-2.3 and
yourlib-1.3.1 which requires foo-2.3.1 and let people choose.
But you will probably make more releases of yourlib, while the
world is still using both foo-2.3 and foo-2.3.1. Argh.
You may make branches, yourlib-1.3.0.x series for foo-2.3 and
yourlib-1.3.1.x series for foo-2.3.1. Then, what if another
library bar, which yourlib depends, also releases an incompatible
new version?

I think complex version reference spec won't solve this problem.
At some point you have to put conditional in your library
based on the API version you're depending.

Andre's suggestion #3 (requiring minimum version) is a nice
compromise. Even in the above scenario, you can still declare
that you won't support anything before foo-2.3. And you support
both foo-2.3 and foo-2.3.1 by switching your code depending
on its version. Though I still think version reference is not
essential at all, when we have means to switch code depending of
the library, and minimum version requirements can be checked by
existing package management tools.

--shiro
Received on Thu Jun 21 2007 - 15:36:30 UTC