Semantic Versioning 2.0.0 - Summary

From this section, it is obvious that we need to follow this rule:

Given a version number MAJOR.MINOR.PATCH, increment the:
  1. MAJOR version when you make incompatible API changes.
  2. MINOR version when you add functionality in a backward compatible manner.
  3. PATCH version when you make backward compatible bug fixes.

If we need to put pre-release label and/or build metadata, we can extend the semver into MAJOR.MINOR.PATCH[-PRERELEASE][+BUILD] format.

The SemVer Specification use keywords from RFC 2119, and this is the summary:

  1. MUST declare a precise-and-comprehensive public API.
  2. MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes.
  3. MUST NOT modify versioned package, create a new version instead.
  4. Major version zero (0.y.z) is for initial development, so the public API SHOULD NOT be considered stable.
  5. Version 1.0.0 defines the public API.
  6. Patch version Z (x.y.Z | x > 0). A bug fix is defined as an internal change that fixes incorrect behavior.
  7. Minor version Y (x.Y.z | x > 0).
    • 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.
  8. Major version X (X.y.z | X > 0). It MAY also include minor and patch level changes.
  9. Pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version.
    • Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92, 1.0.0-x-y-z.--.
  10. Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version.
    • Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3----117B344092BD.
  11. Precedence refers to how versions are compared to each other when ordered.
    • Comparing pre-release versions MUST be determined by comparing each dot separated identifier as follows:
      • Identifiers consisting of only digits are compared numerically.
      • Identifiers with letters or hyphens are compared lexically in ASCII sort order.
      • Numeric identifiers always have lower precedence than non-numeric identifiers.
      • A larger set of pre-release fields has a higher precedence than a smaller set, if all of the preceding identifiers are equal.
    • Build metadata does not figure into precedence.
    • 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta.
    • 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.
    • 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1.

You can see the Backus-Naur Form Grammar here

Golang Implementation

In order to enforce semver, we could create simple golang tools based on golang.org/x/mod/semver package.