asdf version dependency
Robert Goldman
rpgoldman at sift.net
Thu Mar 17 22:10:56 UTC 2016
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.
More information about the asdf-devel
mailing list