Semantic Versioning

Semantic versioning (often abbreviated as SemVer) is a versioning scheme for software that conveys meaning about the underlying changes with each new release. The format is typically in the form of MAJOR.MINOR.PATCH, like 1.2.3. Here's how it works:

1. Version Numbering:

• MAJOR Version (1.x.x): Incremented when you make incompatible API changes.
• MINOR Version (x.2.x): Incremented when you add functionality in a backward-compatible manner.
• PATCH Version (x.x.3): Incremented when you make backward-compatible bug fixes.

For example, in 1.2.3:

• 1 is the MAJOR version.
• 2 is the MINOR version.
• 3 is the PATCH version.

2. Pre-release Labels:

Pre-release versions like Alpha or Beta are used to indicate that a version is still under development or testing and might not be stable yet. These are appended to the version number and often look like this:

• Alpha (1.2.3-alpha): Early testing phase. Might be unstable and lack features.
• Beta (1.2.3-beta): More stable than alpha, but still in testing. Features are mostly complete, but there might still be bugs.
• Release Candidate (RC) (1.2.3-rc): A version that's nearly ready for release. If no significant bugs are found, this could be released as a final version.

3. Build Metadata:

• Additional build information can be added with a plus sign, e.g., 1.2.3-alpha+001.

Putting It All Together:

If you have a version labeled 1.2.3-beta+exp.sha.5114f85, it means:

• Major version: 1
• Minor version: 2
• Patch version: 3
• Pre-release phase: Beta
• Build metadata: exp.sha.5114f85

Version Progression Example:

1. Initial development: 0.1.0 (pre-release versions might be 0.1.0-alpha, 0.1.0-beta, etc.)
2. First stable release: 1.0.0
3. Backward-compatible feature added: 1.1.0
4. Bug fix: 1.1.1
5. Incompatible API change: 2.0.0

Semantic versioning helps developers understand the impact of updating dependencies and encourages a consistent and meaningful versioning practice.

Resources

https://semver.org/