The SemVer Specification outlines the protocol for addressing changes in dependencies without altering the public API. However, the definition of what constitutes a modification to the "public API" remains unclear to me.
NPM Case Study
Imagine a scenario where a library sets a peerDependency on
"foo": "^1.0.0"peerDependency on "foo": "^1.0.1"- An adjustment like this would disrupt a consumer using a
dependencyon
, making it an API-breaking alteration (requiring a major version increment in the library)."foo": "1.0.0" - Most consumers likely use some form of range-based dependency (
, etc.) which should smoothly adapt to this change. Hence, it is not a breaking change to the API."foo": "^1.0.0"
Rust Illustration
Now, consider a library with a dependency on foo = "1.0.0". Would upgrading this dependency to foo = "1.0.1" be considered an API-breaking change? The discourse includes the following excerpt from the documentation.
Multiple versions within the same compatibility range are not allowed and will result in a resolver error if it is constrained to two different versions within a compatibility range.
- A transition like this could hinder any consumer depending on
foo = "=1.0.0", leading to build issues due to conflicting constraints within the same compatibility scope, hence classifying it as an API-breakage. - Generally, most consumers utilizing a range-based dependency will automatically adjust to a suitable new version, signifying a non-API-breaking shift.
- This becomes a breaking change only when we explicitly expose types from
fooin our library. Thus, merely updating the dependency may not warrant labeling it as an "API-breaking change."
The latter perspective aligns closely with SemVer principles, although its application in practice poses uncertainties. Regardless, the subset of affected users remains consistent whether or not we include this particular type in our public API, questioning the significance of considering it a breaking change solely based on that factor.