asdf version dependency

[Faré]

On Thu, Mar 17, 2016 at 6:10 PM, Robert Goldman <rpgoldman at sift.net> wrote:
> On 3/17/16 Mar 17 -4:21 PM, Faré wrote:
>> 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.
>
> In turn, I disagree with this claim strongly.
>
> If I'm the downstream consumer, I can't force the upstream producer to
> change the names of everything when he or she changes the API. (Indeed,
> in the real world, the upstream producer may not even realize when he or
> she has broken a dependent system).  So that won't work.
>
> OK, so you say in that case the old API will have to go by a new name.
> But that doesn't take into account a world in which software development
> resources are finite and often inadequate:  if I don't have time to
> adapt to an API change at the current time (the use case for a version
> upper bound), I CERTAINLY won't have time to fork the upstream library,
> rename everything, and rename everything in my client.
>
Once again, it's OK to use a horrible kluge when under pressure. But
while it's a solution for the INTEGRATOR who releases an application
that depends on an old variant of the library it is no permanent
solution for the USER whose system uses an obsolete API. And if you
are to go forward as the WRITER of the library that uses an obsolete
API, then some day you'll have to pay, one way or the other. In other
words, you've just accrued TECHNICAL DEBT. To pay it, you may:

1- Fix your project to use the latest upstream library (or switch to
another, better one).
2- Introduce a backward compatibility library that implements the old
API on top of the old one (or of different better-managed library).
3- Fork the upstream library because it sucks and/or has stopped
supporting your use case, and rename everything with a few regexps.
4- Take over the upstream library, declare the new API a heresy, and
the old API the One True API. That works great if the library dies or
falls into being unmaintained and unused, and you are its only user
and/or few users if any have adopted the new API because it actually
sucks.
5- Fork the entire world, declare that the new API never happened.
It's very much like option 4, except that the rest of the world
doesn't believe you.
6- Your lucky project manages to die and/or you manage to leave it
before having to pay its debts. Yay! "Not my problem anymore."

Declaring an upper limit on version compatibility is a semi-formal way
of going into solution 5 or 6.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
You may easily play a joke on a man who likes to argue — agree with him.
               — Edgar Waston Howe