mirror of
https://github.com/semver/semver.git
synced 2026-07-11 06:53:03 -05:00
[GH-ISSUE #313] Is it a PATCH version to strict? #1958
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#1958
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 @krzysiekpiasecki on GitHub (Jun 9, 2016).
Original GitHub issue: https://github.com/semver/semver/issues/313
The version in general reflects state of the software. After writing additional unit tests should I release new Minor version? Sounds strange.
I think the problem is that patch is strictly connected only to the bug fixes that corrects invalid behavior.
IMO the better is:
MINOR - Only new software function
PATCH - bug fixes, internal code changes and improvements (faster algorithms, coding standard, tests, etc.)
We just patching existing functions and don't brake MINOR version.
@FichteFoll commented on GitHub (Jun 9, 2016):
See also this discussion: https://github.com/mojombo/semver/issues/215. Tests are not a part of the API, unless you specifically made them so (previously – which I doubt since they didn't exist before).
Though, if you only add tests but don't change anything in functionality, I wouldn't make a release at all. If you do change things (fix them), increase PATCH as for other bugfix releases.
@krzysiekpiasecki commented on GitHub (Jun 10, 2016):
Versioning is all about state of the software and semantic is only a way to name the changes - nothing more.
Every commit has a potential to be a part of the next release and spec should be clear and allow to do it. I still think the patch version is not correct defined. Again patching is not only a bug fixing but also other changes in a state of the software that don't break MAJOR.MINOR version. So lack of documentation is also patching, etc ...
Thanks for a thread #215 @FichteFoll
@xmstspider commented on GitHub (Jun 14, 2016):
What about Major.Minor.Patch.Build for unit tests? I believe this is used in .NET world...
@krzysiekpiasecki commented on GitHub (Jun 14, 2016):
I believe we're distributing the source code with unit tests. The changes in tests should be reflected in a version number not in metadata component.
@arcticicestudio commented on GitHub (Jun 14, 2016):
I'd recommend to merge the new tests into the next regular release version.
But if you want to release a new version only with merged tests, you should increase the MINOR since you wrote additional unit tests which is coverd by
This is seen from your specific case perspective where unit tests are handled as a new functionality.
@krzysiekpiasecki commented on GitHub (Jun 17, 2016):
I'll follow your recommendation @arcticicestudio which is closest to me.
@LinusU commented on GitHub (Nov 11, 2016):
As a module consumer, I feel that it would be very weird if additional test cases where released as a minor release. Since semver is about versioning the public api, and since the tests aren't part of the public api (if the tests is bundled or not is not important, what is important is if it's considered to be a part of your public api).
@jwdonahue commented on GitHub (Dec 7, 2017):
If tests are shipped, they are very much part of the API, as they add documented use cases for those API's.