Semantic Versioning Guidelines and Version Numbering Rules

First, look at some common software version numbers:

Linux Kernel: 0.0.1, 1.0.0, 2.6.32, 3.0.18… When expressed as X.Y.Z, an even Y indicates a stable version, an odd Y indicates a development version.

Windows: windows 98, windows 2000, windows xp, windows 7… The biggest characteristic is chaotic and irregular.

SSH Client: 0.9.8.

OpenStack: 2014.1.3, 2015.1.1.dev8.

From the above we can see that different software version‑number styles vary; as system scale grows and dependencies increase, a lack of a consistent naming scheme can cause Dependency Hell. Therefore, when releasing a version, the version number naming should follow a set of rules. Semantic Versioning 2.0.0 defines a simple set of rules and conditions to constrain version configuration and growth. This article selects and organizes version‑naming guidelines based on Semantic Versioning 2.0.0 and 3.0.0.

Version Number Naming Guidelines

The version format is X.Y.Z (also called Major.Minor.Patch). The increment rules are:

X represents the major version; it must be incremented when API compatibility changes.

Y represents the minor version; it must be incremented when new features are added without affecting API compatibility.

Z represents the patch version; it must be incremented for bug fixes that do not affect API compatibility.

Detailed rules are as follows:

X, Y, Z must be non‑negative integers without leading zeros and must increase numerically, e.g., 1.9.0 → 1.10.0 → 1.11.0.

A version 0.Y.Z indicates the software is in early development and the API may be unstable; 1.0.0 indicates a stable API.

When API compatibility changes, X must be incremented and Y and Z reset to 0; when adding functionality (without affecting API compatibility) or when the API is deprecated, Y must be incremented and Z reset to 0; when fixing bugs, Z must be incremented.

Pre‑release versions indicate instability and possible compatibility issues; format: X.Y.Z.[a‑c][positive integer], e.g., 1.0.0.a1, 1.0.0.b99, 1.0.0.c1000.

Development versions are often used in CI/CD pipelines; format: X.Y.Z.dev[positive integer], e.g., 1.0.1.dev4.

Version ordering compares major, then minor, then patch numerically (e.g., 1.0.0 < 1.0.1 < 1.1.1 < 2.0.0). For pre‑release and development versions: 1.0.0.a100 < 1.0.0, 2.1.0.dev3 < 2.1.0; when letters are present, ASCII ordering applies (e.g., 1.0.0.a1 < 1.0.0.b1).

Note: Once a version is published, its contents must not be altered; any changes require a new version release.

Some Modifier Terms

alpha: internal version

beta: test version

demo: demonstration version

enhance: enhanced version

free: free version

full version: complete or official release

lts: long‑term support version

release: release version

rc: release candidate, soon to become official

standard: standard version

ultimate: flagship version

upgrade: upgraded version

Original source: http://t.cn/REyxWlO

Java Group

WeChat ID: javatuanzhang

Daily sharing of Java technical knowledge

Long press to recognize QR code