So \"myLibrary\" references \"anotherLibrary\". Both libraries follow http://semver.org/
If I release a new version of myLibrary that forces consumers to update to a new
This is specifically answered in the FAQ section of semver, where it is recommended that the major version be not bumped up. http://semver.org/#what-should-i-do-if-i-update-my-own-dependencies-without-changing-the-public-api
It really depends on if the public API of the main library changes. I tend to treat libraries as a black box. I don't need to know the details of how it's implemented. So unless the inner library is exposed somehow then the API of the outer library hasn't changed.
So, if the inner library is not exposed at all, I would bump the patch number and that's it. If the inner library is exposed then you'll have to decide whether that exposure has changed enough to warrant a major version bump (incompatible or breaking change).
Of course if the API of the outer library has changed to support the upgrade of the inner library then a major version bump is warranted.
Unless the library is completely embedded within yours, yes.
Let's say both libraries are on 1.0
. A user could declare their dependencies like:
other ~> 1.0
yours ~> 1.0
Where ~>
means a dependency on any version compatible with 1.0
, i.e. 1.x.y
.
Your library declares:
other ~> 1.0
So everything works, and dependencies can resolve. If other
moves to 1.1.0
, everything still works.
Now, your library switches to:
other ~> 2.0
...and releases this as version 1.1.0
. This is incompatible with the user's declared dependencies. They want a 1.x
version of other
and a 1.x
version of yours
, which previously worked, but now doesn't. Therefore, you must release this as version 2.0
. Even if your library doesn't expose any symbols with types from the dependency library, you've broken the user's dependency management.