mirror of
https://github.com/semver/semver.git
synced 2026-03-10 16:02:25 -05:00
Is the PATCH needed? #90
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#90
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 @bessarabov on GitHub (Jul 18, 2013).
I like SemVer much, but I have heard a question that I was not able to answer.
The question is "Is the PATCH needed?"
I understand that the main idea of SemVer is to make things simple and to try to avoid "dependency hell."
Adding PATCH (
x.y.Z) does not solve any of this 2 goals. But instead it adds a bit of difficulties. If there was no PATCH in the version you can use pure numeric comparison to compare 2 versions in the formatx.y.The number
x.y.zlooks very pretty, but what are the real purposes why we need PATCH?PS this question was born because of the discussion http://questhub.io/realm/perl/quest/51d303b4ecc7889b40000025
@haacked commented on GitHub (Jul 18, 2013):
It's right there in the SemVer spec:
I think there's a real need to identify a new version that is backwards compatible in such a way. It communicates something that having only Major and Minor could not communicate. That's the real benefit of SemVer. It can't prevent "dependency hell" but it can mitigate it by providing a unified way to communicate how different versions have changed.
Also, SemVer is born from distilling practices that were already in existence long before SemVer was around. The idea of a PATCH version was not created by SemVer. It's a long established practice that many communities have found useful.
@EddieGarmon commented on GitHub (Jul 18, 2013):
Also, not explicitly stated, but
x.yis the specific version of an API, andzis the number of bug-fix releases of that API.@bessarabov commented on GitHub (Jul 18, 2013):
@Haacked I don't get it. Changing a PATCH version creates the release that is backwards compatible. Changing MINOR version also creates the release that is backwards compatible. What is the difference for the release user?
The argument "It exists for a long time and because of it is is correct" is a bad argument. =)
@bessarabov commented on GitHub (Jul 18, 2013):
@EddieGarmon why do I need to bother for the
yinx.yversion? There is a state in semver:If I'm a user of some library that users semver, then I worry only about changing MAJOR version number, because it breaks API. Am I right that it does not matter for the end user what change it was — bugfix or some backwards compatible functionality is introduced?
@EddieGarmon commented on GitHub (Jul 18, 2013):
backwards compatible functionality is introduced to the public API.usually means you added additional types or methods, such that consumers of 1.5 can use 1.6 without taking advantage of the new features and know that they should not break. Ideally this can be done without a recompile for a code based Public API.In the notion of a specification, such as SemVer, adding a BNF grammer to the spec (see #116) would be new backwards compatible functionality moving the spec to 2.1.0.
@bessarabov commented on GitHub (Jul 18, 2013):
@EddieGarmon I completely agree with you =) But I haven't understood from your answer why we need to separate PATCH from MINOR.
@EddieGarmon commented on GitHub (Jul 18, 2013):
A patch does not add any new api, where a minor does.
@bessarabov commented on GitHub (Jul 18, 2013):
Yes. But what task we are solving with dividing this 2 things into 2 things? Why can't we only change MINOR part (and remove PATCH part from the standard).
In this idea changing MINOR part means that there is no backwards-incompatible changes.
What is the use for the end user to know what has been changed — was is new methods or there were some bug fixes?
@EddieGarmon commented on GitHub (Jul 18, 2013):
This.
Minor, means yes new features and maybe bug fixes
Patch, means only bug fixes
Some consumers do want to limit a specific dependent API version, but want all the latest bug fixes for that major.minor version
@taringamberini commented on GitHub (Jul 18, 2013):
If you see a Minor increment you might be interested in which new functionalities have been introduced or have been deprecated. The former might be useful to improve your code, the latter might be useful to estimate and/or plan refactoring of your code when a next Major increment will happen and such Major will remove the functionalities preceding deprecated.
Usually if a Patch increment occurs I surely will not be interested in improving my code or planning refactoring. Nevertheless you might be using an awful workaround because a bugged functionality, in that case you might be interested about when the bug will be fixed.
Discriminate between Minor an Patch lets you act differently.
@bessarabov commented on GitHub (Jul 19, 2013):
@EddieGarmon Thank you for the patience for explaining everything to me =)
If I understood you correctly the consumer specifies that his product works with library that has x.y.z version, where
xandyare some fixed numbers, andzcan be any number. Ok. In this situation current version of SemVer make sense.I'm awfully sorry, but still not not everything is clear for me. Why does the consumer wants to have
x.yto be freezed? Why it is not enough for him to freeze onlyxpart of the version?@EddieGarmon commented on GitHub (Jul 19, 2013):
In an enterprise IT organization, for example, this could just be the rule. This could be because of the vetting policies, or maybe just politics. The current spec is designed to support this type of scenario also. If there was no patch, then there would be people that would be impacted by organizational rules only allowing bug fixes to vetted dependencies. Most importantly to understand is that it is their choice and not something that we should mandate.
I suspect that in most cases, dependencies will be specified on the range [x.y, x+1) or [x.y.z, x+1), which says all non-breaking changes are allowed. But again, I'm speculating here.
@oberhamsi commented on GitHub (Jul 19, 2013):
i feel @taringamberini already said it wellː a chanɡe in y - deprecation and new features - are more siɡnificant then a chanɡe in z. if dependencies chanɡe their y, the consumer should take a look at whats ɡoinɡ on and what direction thinɡs are takinɡ.
@bessarabov commented on GitHub (Jul 20, 2013):
I want to thank everybody in this thread for explaining this matter to me. As I understood, the SemVer is designed to give the consumer several ways to manage deps.
@Haacked, @oberhamsi, @EddieGarmon, @taringamberini, Thank you! =)