3 ms·
> but if a library is repeatedly releasing one broken version after another, you probably just shouldn't use it. Your assumption here is that it was the boring
by irishsultan 8y ago
> but if a library is repeatedly releasing one broken version after another, you probably just shouldn't use it.
Your assumption here is that it was the boring-library version 1.5 that was broken, in reality it could be that they changed something that wasn't documented and was only an implementation detail, but was relied on by cool-framework (e.g. getting a list back sorted in one particular way in 1.4 and sorted in another way in 1.5 where the order was never part of the API contract).
- zenhack 8y agoGood point. In this case, the bug is in cool-framework, and I don't know that I see a great solution, regardless of the expressiveness of the constraint system. Ultimately I don't think there's a way to rule that out short of specifying exact versions. Unfortunately you can't retroactively change the version bounds for an existing release, so any library that specifies an upper bound admitting any yet-to-be-released version runs this risk.