mirror of
https://github.com/semver/semver.git
synced 2026-07-10 19:50:47 -05:00
[GH-ISSUE #429] Questions about Minor Changes #5433
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#5433
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @jon-whit on GitHub (Feb 23, 2018).
Original GitHub issue: https://github.com/semver/semver/issues/429
According to the SemVer specification, the MINOR version MUST be incremented if new backwards compatible changes are made to the public API.
What if new functionality is added to an internal API that doesn't change the public API? Are there any recommendations on bumping version numbers if the internal API changes but does so in a way that is compatible with the existing public API? Should the version be bumped at all in this case?
@foxbit19 commented on GitHub (Feb 23, 2018):
Hi @jon-whit, I think there must be an increase of the MINOR version even if the new functionality is added to an internal API. The version increments represent a change that distinguish previous version from current version of your code.
I always think about incremental code obfuscation in this case: consequentials releases (with different version numbers) that are semantically equivalent but hardening the reverse engineering job.
@FichteFoll commented on GitHub (Feb 23, 2018):
The internal API is completely separate from the public API and does not matter in the semver scope. Changing anything in the internal API is entirely transparent to the public API, so this is a patch level change.
@jwdonahue commented on GitHub (Feb 26, 2018):
Actually it doesn't say that at all. You are referring to https://semver.org/#spec-item-7, which references the public API. It does say that it MAY be incremented "if substantial new functionality or improvements are introduced within the private code".
@jon-whit, unless you have further questions, please close this issue at your earliest possible convenience.
@jon-whit commented on GitHub (Feb 26, 2018):
@jwdonahue thanks!