The open-data portal client library adds a new optional endpoint while keeping all existing endpoints behaviorally unchanged. Which SemVer bump is appropriate?
Select an answer to reveal the explanation.
Short Explanation
MINOR is the ‘new wing on city hall, old doors still work’ bump. You added an optional open-data endpoint without breaking the old ones — celebrate with a minor version, not a false major alarm.
Full Explanation
Semantic Versioning assigns MINOR bumps to backward-compatible feature additions. Adding a new optional endpoint to the open-data portal client library while keeping all existing endpoints behaviorally unchanged is exactly that case: callers that ignore the new endpoint continue to work, and teams that want the capability can adopt it on their schedule. Publishing a MINOR version communicates additive capability without a breaking contract change.
A MAJOR bump is for incompatible changes; a new optional path does not break callers by itself. A PATCH bump covers compatible fixes, not new features, and is not “reserved only for removing public methods”—removal of public methods is typically MAJOR. Resetting the version to 0.0.1 to signal a soft launch discards SemVer communication and confuses consumers pinning the library.
Exam caveat: if the “new” endpoint changed existing response shapes or required new mandatory parameters on old calls, MAJOR would apply; the stem’s unchanged behavior forces MINOR. Operational check: publish the minor, run consumer smoke tests without calling the new endpoint, then enable the new call in a canary client and confirm both paths succeed. Document the new optional endpoint in the MINOR release notes so open-data consumers discover it without treating silence as a hidden breaking change. Pinning guidance should allow ^minor ranges for teams that accept additive updates.