On Thu, Mar 17, 2016 at 6:10 PM, Robert Goldman rpgoldman@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