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.