mirrors/semver
0
0
Fork 0
mirror of https://github.com/semver/semver.git synced 2025-08-22 22:08:33 +00:00
Code

Change MUST reset to SHOULD reset

Browse Source 
As this is relaxing a constraint, it would be a minor update (2.1) to the specification - all existing implementations would remain compliant.

The relaxation of the increment by 1 requirements from SemVer 1.0 allowed, where it was necessary, to skip an increment, e.g. from release 2.4.10, change to 2.6.0 (or 4.0.0).

But, as the specification currently stands it would not be possible change from 2.4.10 to 2.5.1 - it MUST be 2.5.0 (or 2.6.0, etc).

Changing from MUST to SHOULD still encourages the reset, but allows for situations where it is not followed.

Example, moving from version 2.4.10, there could be an extensive period of 3.0.0-beta.1, 3.0.0-beta.2, etc, that never actually gets released, but is widely known; if the decision is made to skip a version, then this change would allow 3.1.0 to be developed (releasing 3.1.0-beta.1, etc) and eventually released (as 3.1.0). Without this change, the only option would be to bump to 4.0.0.
This commit is contained in:
Sly Gryphon 2017-09-07 21:28:03 +10:00
parent d58db16863
commit 74df6f3e4a
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
semver.md
View File

@ -83,11 +83,11 @@ compatible functionality is introduced to the public API. It MUST be
incremented if any public API functionality is marked as deprecated. It MAY be
incremented if substantial new functionality or improvements are introduced
within the private code. It MAY include patch level changes. Patch version
MUST be reset to 0 when minor version is incremented.
SHOULD be reset to 0 when minor version is incremented.
1. Major version X (X.y.z | X > 0) MUST be incremented if any backward
incompatible changes are introduced to the public API. It MAY also include minor
and patch level changes. Patch and minor versions MUST be reset to 0 when major
and patch level changes. Patch and minor versions SHOULD be reset to 0 when major
version is incremented.
1. A pre-release version MAY be denoted by appending a hyphen and a
@ -115,30 +115,30 @@ have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700,
minor, patch and pre-release identifiers in that order (build metadata
does not figure into precedence).
1. Precedence is determined by the first difference when comparing each of
2. Precedence is determined by the first difference when comparing each of
these identifiers from left to right as follows: major, minor, and patch
versions are always compared numerically.
Example: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1.
1. When major, minor, and patch are equal, a pre-release version has lower
3. When major, minor, and patch are equal, a pre-release version has lower
precedence than a normal version:
Example: 1.0.0-alpha < 1.0.0.
1. Precedence for two pre-release versions with the same major, minor, and
4. Precedence for two pre-release versions with the same major, minor, and
patch version MUST be determined by comparing each dot separated identifier
from left to right until a difference is found as follows:
1. Identifiers consisting of only digits are compared numerically.
1. Identifiers with letters or hyphens are compared lexically in ASCII
2. Identifiers with letters or hyphens are compared lexically in ASCII
sort order.
1. Numeric identifiers always have lower precedence than non-numeric
3. Numeric identifiers always have lower precedence than non-numeric
identifiers.
1. A larger set of pre-release fields has a higher precedence than a
4. A larger set of pre-release fields has a higher precedence than a
smaller set, if all of the preceding identifiers are equal.
Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta <