Should major SemVer updates cascade?

问题:

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 major version of anotherLibrary should the major version of myLibrary also increment?

回答1:

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

回答2:

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.

• No outer API change - update patch number
• Outer API exposes inner library type - update minor or major version
• Outer API changed - update minor or major depending on level of change

回答3:

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.