Semantic versioning specification

A, problem,

In the absence of a unified semantic versioning specification, a developer may install a package and find that it relies on other packages of different versions. As the system becomes more and more complex and relies on more and more software packages, there is a risk that version control will be locked, which is known as “dependency hell”.

Second, description,

The specification for semantic version control was developed by Gravatars founder and GitHub cofounder Tom Preston-Werner. Semver.org/

The outline of the specification is as follows: Version format: Major version number. Second version. Revision number

  1. Major release number: functional-led planned implementation, incompatibility modifications.
  2. Minor version number: Backward compatible functionality additions and modifications.
  3. Revision number: Backward compatible problem fix.
  4. Revision number: used to fix problems, using incremental method.

Semantic version control specification

  1. The standard version number must be in the XYZ format, and X, Y, and Z must be non-negative integers. Zero padding before the number is prohibited. The version release must be strictly incremented. For example, 1.9.1 -> 1.10.0 -> 1.11.0.
  2. After a version is released, it is prohibited to change the content of that version. Any changes must be based on the new release.
  3. Software with a major version number of 0 (0.y.z) is identified as being in the initial stage of development, and everything is subject to change or change at any time. The public API provided by such a release should not be considered stable.
  4. The version number of 1.0.0 is used to define the formation of the official version. Version 1.0.0 can be released when the software is released to a formal environment or has stable API functionality.
  5. Second version number (X.Y.Z Y | x > 0) must be backwards compatible in increasing new features emerged. It can also be incremented when a large number of new features or improvements are added to the internal program. The revision number must return to zero each time the version number increases.
  6. Revision number Z (X.Y.Z | x > 0) must be in only for backward compatibility of incremental correction. Corrections here refer to internal modifications made in response to incorrect results, such as functional defects on the line, etc.
  7. The major version number (X.Y.Z X | X > 0) must be in increasing the compatibility of modified, such as the emergence of a new functional requirements. Each time the major version number increases, the minor version number and revision number must return to zero.
  8. Version priority refers to how different versions compare in order. When determining the priority level, you must divide the version number into the major version number, the minor version number, the revision number, and the earlier version number for comparison.
  9. The prior version number can be marked after the revision, with a join number followed by a series of identifiers separated by periods. The identifier must consist of ASCII alphanumeric characters and join numbers [0-9A-ZA-Z -]. White space is prohibited. The prior version has a lower priority than the associated standard version. A prior release number indicates that the release is not stable and may not meet the expected compatibility requirements. For example: 1.0.0 – alpha, 1.0.0 – alpha. 1, 1.0.0 0.3.7, 1.0.0 x. 7. Z. 92
  10. Version priority refers to how different versions compare in order. When determining the priority level, you must divide the version number into the major version number, the minor version number, the revision number, and the earlier version number for comparison. Each identifier is compared from left to right. The first difference value is used to determine the priority level. Major, minor, and revision numbers are compared in numerical terms, for example: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1.

If the major version number, minor version number, and revision number are all the same, the earlier version number with lower priority is used. For example: 1.0.0-alpha < 1.0.0. The precedence of two prior versions with the same major, minor, and revision numbers must be compared by each period-separated identifier from left to right until a difference value is found. Numeric identifiers are compared in numeric order, or in ASCII order when there are letters or join numbers. Priority determination example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.

Iv. Actual case description

Take a look at the React release logs for the last 5 months, one of the most popular front-end frameworks:The following conclusions can be drawn from the figure: 1. The software version usually consists of three parts, such as X.y.z2. The version is strictly incremental, here: 16.2.0 -> 16.3.0 -> 16.3.1 3. When releasing important versions, you can release alpha, rc, etc. 4. The alpha and rc keywords can be added with the numbers and meta information. This is thanks to the Semver(semantic version) specification.

Here is the React dependency graph that follows the Semver specification:Semver compliant package dependencies are very clear, with no recurring dependencies, dependency conflicts, and other common problems

This article was created and shared by Mirson. For further communication, please add to QQ group 19310171 or visit www.softart.cn