mirror of
https://github.com/semver/semver.git
synced 2026-07-11 04:52:47 -05:00
[GH-ISSUE #292] How to handle non-api changes? #6201
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#6201
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 @Lucretiel on GitHub (Feb 7, 2016).
Original GitHub issue: https://github.com/semver/semver/issues/292
Let's say I merge a number of pull requests that add a bunch of test coverage, introduce commenting, or update the documentation that ships with the project. How should I handle the version number in these cases? Any or all of these changes could be part of a "release," as they're downloaded with the package. The former case is interesting because it affect people who run the tests, but not the typical client of the library. Are any of these considered "bug fixes," if nothing about the actual usage or API of the project changes? My instinct is to simply revise an existing version (prohibited by rule 3). Would this be a patch revision? Build metadata?
@FichteFoll commented on GitHub (Feb 7, 2016):
Imo either minor or patch, depending on how tests are part of the API, favoring patch.
@PowerKiKi commented on GitHub (Feb 8, 2016):
I'd go for patch too
@crazedsanity commented on GitHub (Feb 8, 2016):
I increment the patch level in these cases.
@manbusky commented on GitHub (Mar 12, 2016):
Such as performance optimization, I will increase the patch.
@jwdonahue commented on GitHub (Dec 1, 2017):
@Lucretiel, unless you have any further questions on this matter, please close this issue.