Menu
The rules for when to increase the MAJOR vs the MINOR version number with SemVer 2.0 are very compelling. They clearly give a lot of advantages to knowing if the app/service is backwards compatible.
But the site does not really give an reason for the differences between a MINOR and what it calls a PATCH. I don't see it giving the same benefits of MAJOR vs MINOR.
For reference here are the SemVer rules:
So the only difference between MINOR and PATCH is features vs bug fixes. My company wants to do that differently.
They want to have MINOR be a collection of [backwards compatible] features. "PATCH" (which we call Incremental) be the releases needed to get those features out. (We release bug fixes as we release features.)
For example, if we plan for 7 [backwards compatible] features in our 2.4 release then 2.4.0 may have 2 of the features, 2.4.1 would have 3 more features and 2.4.2 would have the last 2 (perhaps with a bug fix or two in each release).
I can see that this violates SemVer, but I need to know why SemVer has decided to be prescriptive on the differences between the MINOR and PATCH versions so I can know which way to push my company.
NOTE: I hope that this is not too subjective for Stack Overflow. I don't usually ask questions like this, so it is possible that this question will need to be closed...
470
MAJOR version increment indicates incompatible API changes. MINOR version increment indicates addition of functionality in a backwards-compatible manner. PATCH version increment indicates backwards-compatible bug fixes.
"PATCH" (which we call Incremental) be the releases needed to get those features out. (We release bug fixes as we release features.) For example, if we plan for 7 [backwards compatible] features in our 2.4 release then 2.4.
Minor versions are incremented when you add functionality to your app or library. These new functions should not affect the functions in the older version. Users of your app or library should not be required to update their dependencies because minor versions are meant to be additive, not corrective.
Minor Version means a revision of the Software that includes new minor features or minor changes to the already existing features on the previous minor version of the Software.
The semver spec doesn't explicitly state the maximum semver, however JavaScript's MAX_SAFE_INTEGER constant has a value of 9007199254740991. So, using the npm tools the maximum major, minor, patch in a semver is; 9007199254740991.9007199254740991.9007199254740991.
Because this is a patch, our users know they can safely upgrade without rigorously testing their programs. But the feather wasn’t introduced in this major release, it was introduced in an older version. If we want to keep supporting our user base, we should release a patch to our old versions as well.
valid (v): Return the parsed version, or null if it's not valid. premajor in one call will bump the version up to the next major version and down to a prerelease of that major version. preminor, and prepatch work the same way. If called from a non-prerelease version, the prerelease will work the same as prepatch.
If a partial version is provided as the first version in the inclusive range, then the missing pieces are replaced with zeroes.
The standard is deliberately terse. There's nothing in it that prevents you from releasing a bunch of bug fixes along with your new features and you only have to bump the minor field when you do this. If the changes only involve bug fixes, refactoring or documentation that does not add, remove or modify any interface, then you only bump the patch. The whole point is to communicate to your consumers, their level of risk when taking an update from you.
EDIT: It is a best practice to separate bug fixes (patches) from feature work (minor) and breaking changes (major), into separate releases. This allows your consumers to automatically pick up the latest fixes, without having to deal with feature bloat or breaking changes.
82
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
