The Standard Versioning is a maturity-oriented versioning scheme, defined by the following version identifier scheme: The Standard Versioning version identifier scheme usually is used at the following three distinct levels, which are most popular in practice and directly align to the usual extend of the particularly used release management:

• Level 0: M.N.R
  Standard Versioning, just with release revisions and excluding the optional parts.
• Level 1: M.NpR
  Standard Versioning, excluding the optional parts.
• Level 2: M.NpR [.D] [+H] [-S]
  Standard Versioning, including the optional parts (when necessary).

The parts of the Standard Versioning version identifier scheme are:

• M: \d+ (M ≥ 0) — Major Version
  Major version of solution.
  Rationale: Primary versioning of solution.
  • Bumped by provider on major changes, like full modernizations. A bump resets the Minor Version N to 0, Release Phase p to Release (for Level 0) or Alpha (for Level 1 and 2), Release Revision R to 0, and drops Snapshot Date D and Source Hash H.
  • On change by provider, backward compatibility is not possible. On upgrade by consumer, human interaction is expected.
• N: \d+ (N ≥ 0) — Minor Version
  Minor version of the solution within the Major Version.
  Rationale: Primary versioning of solution.
  • Bumped by provider on minor changes, like new features. A bump resets the Release Phase p to Release (for Level 0) or Alpha (for Level 1 and 2), Release Revision R to 0, and drops Snapshot Date D and Source Hash H.
  • On change by provider, backward compatibility is seeked for, but not assured. On upgrade by consumer, human interaction might be required.
• p: (?:a|b|rc|\.) — Release Phase
  Release phase within the combination of Major Version M and Minor Version N.
  Rationale: Integrate maturity phase.
  • The distinct phases, in chronological order, are:
    • a — Alpha
      Early version of the solution with incomplete and unstable functionalities, to get feedback on solution.
    • b — Beta
      Early version of the solution with complete but still unstable functionalities, to stabilize solution.
    • rc — Release Candidate
      Mature version of the solution with complete and stable functionalities, to catch final inconsistencies just before release.
    • . — Release
      Mature version of the solution with complete and stable functionalities, available for full production use.
  • Bumped by provider on entering a new maturity phase of the solution. A bump resets the Release Revision R to 0 and drops Snapshot Date D and Source Hash H.
  • On change by provider, backward compatibility is seeked for, but not assured. On upgrade by consumer, human interaction might be required.
• R: \d+ (R ≥ 0) — Release Revision
  Release revision of the Release Phase p within the combination of Major Version M and Minor Version N.
  Rationale: Revision counter within release phase.
  • Bumped by provider on every revision within a Release Phase p. A bump drops Snapshot Date D and Source Hash H.
  • On change by provider within Alpha and Beta maturity phases, no backward compatibility has to be assured. On change by provider within Release Candidate and Release maturity phases, full backward compatibility has to be assured. On upgrade by consumer, no human interaction is required.
• D: \d{8} — Snapshot Date
  The optional snapshot date of year, month and date, represented in sort-supporting ISO notation.
  Rationale: Support snapshots between official versions.
  • Bumped by provider on new snapshots within a Release Revision R. A bump just updates Snapshot Date D to the current date and drops the Source Hash H.
  • On change by provider within Alpha and Beta maturity phases, no backward compatibility has to be assured. On change by provider within Release Candidate and Release maturity phases, full backward compatibility has to be assured. On upgrade by consumer, human interaction might be required.
• H: [\dA-F]{4} — Source Hash
  The optional 16-bit hash of the source state of the solution, represented as a upper-case hexadecimal value. This is an, at build-time automatically calculated, SHA-254 digest (32 bytes, 256 bit), folded 4 times through an XOR-operation into just 2 bytes / 16 bit.
  Rationale: Support sub-daily snapshots and easy build identification during developer hot-reloading round-trips.
  • Bumped by provider on any build within Release Revision R. A bump just drops Source Hash H, as it afterwards has to be set manually.
  • On change by provider, no backward compatibility has to be assured. On upgrade by consumer, human interaction might be required.
• S: [XLEG]A — Release Scope
  The optional availability scopes of the release.
  Rationale: Support intended availability scope of release.
  • The known availability scopes are:
    • XA: No Availability
      No public availability of solution at all. The scope for all Development and sometimes Snapshot point-in-times.
    • LA: Limited Availability
      Limited public availability of solution. Usually for releases after the End-of-Life-Announcement (EOLA) or for releases with specific customer features.
    • EA: Early Availability
      Early public availability of solution for early market. Usually for Beta or Release Candidate levels or for Release and initial Release Update levels.
    • GA: General Availability
      Late public availability of solution for mainstream market. Usually for Release and sometimes just for Release Update levels.
  • Bumped by provider on entering a new release scope of the solution.
  • On change by provider, backward compatibility is seeked for, but not assured. On upgrade by consumer, human interaction might be required.

The following are version examples of the life-cycle excerpt of a fictive solution, based on Standard Versioning Level 0, where just release versions are used:

• 1.1.4: {{ explain("1.1.4") }}
• 1.2.0: {{ explain("1.2.0") }}
• 1.2.1: {{ explain("1.2.1") }}
• 1.2.2: {{ explain("1.2.2") }}

The following are version examples of the life-cycle excerpt of the same fictive solution, based on Standard Versioning Level 1, where also pre-release versions are used to support development phases:

• 1.1.4: {{ explain("1.1.4") }}
• 1.2a0: {{ explain("1.2a0") }}
• 1.2a1: {{ explain("1.2a1") }}
• 1.2b0: {{ explain("1.2b0") }}
• 1.2b1: {{ explain("1.2b1") }}
• 1.2b2: {{ explain("1.2b2") }}
• 1.2rc0: {{ explain("1.2rc0") }}
• 1.2.0: {{ explain("1.2.0") }}
• 1.2.1: {{ explain("1.2.1") }}
• 1.2.2: {{ explain("1.2.2") }}

The following are version examples of the life-cycle excerpt of the same fictive solution, based on Standard Versioning Level 2, where optional date, source state hash and availability scope information are additionally used to especially also support snapshots, developer round-trips and varying availability scopes:

• 1.1.4-GA: {{ explain("1.1.4-GA") }}
• 1.2a0-LA: {{ explain("1.2a0-LA") }}
• 1.2a0.20230821+42FA-XA: {{ explain("1.2a0.20230821+42FA-XA") }}
• 1.2a0.20230821+42CB-XA: {{ explain("1.2a0.20230821+42CB-XA") }}
• 1.2a1-LA: {{ explain("1.2a1-LA") }}
• 1.2a1.20230824-LA: {{ explain("1.2a1.20230824-LA") }}
• 1.2b0-LA: {{ explain("1.2b0-LA") }}
• 1.2b1-LA: {{ explain("1.2b1-LA") }}
• 1.2b2-LA: {{ explain("1.2b2-LA") }}
• 1.2rc0-EA: {{ explain("1.2rc0-EA") }}
• 1.2.0-EA: {{ explain("1.2.0-EA") }}
• 1.2.1-GA: {{ explain("1.2.1-GA") }}
• 1.2.1.20230831-LA: {{ explain("1.2.1.20230831-LA") }}
• 1.2.2-GA: {{ explain("1.2.2-GA") }}

To online decode a Standard Versioning identifier, one can just prefix it with https://stdver.org# and open the resulting URL in any Web browser. An example URL follows:

https://stdver.org#1.2.3.20230810+ABCD-XA

To offline decode a Standard Versioning identifier, one can use the stdver(1) Command-Line Interface (CLI) in a Node.js environment:

$ stdver explain -f text  1.2.3.20230810+ABCD-XA
$ stdver explain -f table 1.2.3.20230810+ABCD-XA

To offline decode a Standard Versioning identifier programatically, one can use the stdver NPM package in a Node.js environment:

import StdVer from "stdver"
const stdver = new StdVer()
const text = stdver.explain("1.2.3.20230810+ABCD-XA",
    { format: "text", markup: "none" })
console.log(text)

To match a Standard Versioning identifier, one can use the following Regular Expression (RegExp):

\d+\.\d+(?:a|b|rc|\.)\d+(?:\.\d{8})?(?:\+[\dA-F]{4})?(?:-[XLEG]A)?

To match and decode a Standard Versioning identifier, one can use the following Regular Expression (RegExp) which contains the necessary capture groups:

(\d+)\.(\d+)(a|b|rc|\.)(\d+)(?:\.(\d{8}))?(?:\+([\dA-F]{4}))?(?:-([XLEG]A))?

Beside Standard Versioning there are other popular versioning schemes, each with their pros and cons and with distinct differences to Standard Versioning.

Semantic Versioning is strict versioning scheme, based on three version numbers where each version number is incremented when a certain class of change was done. The types of changes are backward compatible bugfixes, backward compatible new functionality, and backward incompatible changes. Hence, Semantic Versioning primarily is compatibility-driven.

PRO: One knows exactly what compatibility to expect from such a version number. Its base part of the versions also follows the widespread scheme of three positional numbers and this way meets the version identifier representation expectation of many people.

CON: The compatibility-driven semantics are useful in practice, but when it comes to version identifiers, the intuition of many people is primarily maturity-oriented and just secondarily compatibility-driven. Also, the maturity phase (pre-release) information is just attached instead of fully integrated and hence confusing for some edge cases. For instance, 1.2.3-alpha.4 would denote the 4th alpha of version 1.2.3, but as the 3 of 1.2.3 in Semantic Versioning is a strict patchlevel for fully compatible bugfixes, why should an alpha version exists for such a situation anyway?!

Calendrical version identifiers like 2023.08 are a versioning scheme, which usually is based on year and month information and in represented in sort-supporting ISO date notation.

PRO: Calendrical version identifiers combine the intuition of traditional double-number based versions with the release point in time.

CON: Because of the maximum of a month resolution, they fit primarily to large solutions with long release-cycles only, and especially do not work well for solutions with small release-cycles.

Marketing version identifiers like (Windows) Vista, (macOS) Ventura or (Debian GNU/Linux) Bookworm are based on codenames, usually derived from non-reserved/non-registerable names of places, people, etc.

PRO: Those version identifiers are nice for marketing solutions, as they can be easily pronounced and are rather catchy.

CON: Those version identifiers carry no maturity and/or compatibility semantics at all and hence in practice always have to be combined with underlying technical version identifiers.

The Standard Versioning dates back to early definitions in the year 2008 by Dr. Ralf S. Engelschall in the context of its Software Architecture trainings. It was formally defined and publically published on stdver.org in 2023 to have a convenient reference at hand on the Web.

Standard Versioning is motivated by the usual maturity-based intution most people have in mind when it comes to solution versions. It also integrates the recurring revisions of maturity phases directly into the version. Finally, it knows the optional tagging of versions with snapshot date, source hash and availability scope in order to support snapshot versions, development versions and different target customer scopes.