Menu
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?
922
You must update to a major version when changes you're making in a potential new version can't guarantee backward compatibility for the module's users. For example, you'll make this change if you change your module's public API such that it breaks client code using previous versions of the module.
Major change: a change that requires a major SemVer bump. Minor change: a change that requires only a minor SemVer bump. Possibly-breaking change: a change that some projects may consider major and others consider minor.
Semver is a specification outlining a method of encoding the nature of change between releases of a "public interface", directly into the version string. A public interface could be anything from an application programming interface (API), a command-line interface (CLI) or a graphical user interface (GUI).
MAJOR version increment indicates incompatible API changes. MINOR version increment indicates addition of functionality in a backwards-compatible manner. PATCH version increment indicates backwards-compatible bug fixes.
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
142
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
