Dec 4, 2013 at 1:23 AM
Edited Jan 6, 2014 at 4:20 PM
Generally, the guidance in most cases is to only specify a lower bound, and leave the upper bound open.
How do we deal with backwards-incompatible releases? If the upper bound is open you could easily update a dependency to a backwards-incompatible version.
Is there currently a way to deal with this issue? Dependencies are not an updatable metadata. If I leave the upper bound open I'd have to:
- Test new releases of the dependency, make sure it's compatible, specially minor and major versions. If not, create a new release that closes the upper bound.
If I leave the upper bound closed I'd have to:
- Create new releases when the dependency version exceeds the range. I'd have to bet that the dependency will keep backwards compatibility, either in a major version or, more conservatively, in a minor version.