asdf version dependency

[Faré]

On Wed, Mar 16, 2016 at 8:06 PM, Robert Goldman <rpgoldman at sift.net> wrote:
> No, I am afraid you cannot do that yet.  I have long wanted to add
> version upper bounds.  This would be very useful for cases where one
> knows that a library has changed its API, but you have not yet adapted
> your system to the changed API.  [Think of all of those systems that
> still must be compiled with old GCC, or that use Python 2, instead of 3,
> etc.]
>
I strongly disagree. If a controversial major incompatibility is
introduced that causes a lot of software not to migrate to the new
API, the right thing to do is to fork the damn library. Either the old
API or new API will have to go by a new name.

You can keep calling your software informally Python 2 and Python 3,
but the system-name as far as ASDF is concerned will be "cl-python2"
and "cl-python3". If the old one was called "cl-python" and you want
to keep the name after the major incompatible API changes, you have to
tell those who refuse to upgrade that they will have to fork your
library and they will from now on have to use "cl-python2" as their
dependency instead of "cl-python".

ASDF has restrictions on the version strings it accepts. It's OK to
have restrictions on the naming conventions users may have. No, you
can't have two divergent majorly incompatible libraries have the same
name, be distinguished by version only, and expect the ASDF version
system to help you. Just nope.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
- We're all different.
- I'm not!