Semantic Versioning
Semantic Versioning (SemVer) uses MAJOR.MINOR.PATCH numbers to show how a public API changed. It also sets rules for prerelease and build labels.
Another example
A library is at 2.4.1 and adds an API that still works with old code. The maintainer releases 2.5.0 and records the addition. Without a stated public API, these numbers cannot clearly promise compatibility.
Main parts
- 01public API
- 02compatibility change
- 03version identifier
Use it when
Use this term for software with a stated public API whose release numbers show compatibility changes.
Do not use it when
Do not guess product quality, release date, or upgrade work from a SemVer number alone.
Name used in code
MAJOR.MINOR.PATCH[-prerelease][+build] Before you ship
Check the runtime and version, integration limits, dependencies and licenses, and platform support. Verify security, failure, speed, monitoring, deploy, support owner, upgrade path, and rollback.
Outcome: Use or review Semantic Versioning as a technical building block that the team can maintain. User context: A library is at 2.4.1 and adds an API that still works with old code. The maintainer releases 2.5.0 and records the addition. Without a stated public API, these numbers cannot clearly promise compatibility. Technology or engineering concept: Semantic Versioning. Why it fits: Use this term for software with a stated public API whose release numbers show compatibility changes. Do not use it when: Do not guess product quality, release date, or upgrade work from a SemVer number alone. Engineering fit: Define where it runs and which version to use. Set its job, interfaces, data flow, dependencies, supported systems, security, and speed limits. Explain how it fits the current stack. Lifecycle safeguards: Check dependency health and licenses. Add monitoring and a fallback. Name the upgrade owner. Do not add a second tool for the same job without a measured benefit. Acceptance criteria: A small integration proves the needed behavior. Test compatibility, security, failure, and performance. Document deploy, upgrade, support, and rollback steps. Evidence and limits (evidence boundary): A formal document may still be a draft, release candidate, or final version. Check its status and browser or platform support. Unknowns to confirm: Current stack, runtime and version rules, target systems, dependency owner, performance budget, support period, and migration limits.
Check this request
Review the current use of Semantic Versioning. Definition: Semantic Versioning (SemVer) uses MAJOR.MINOR.PATCH numbers to show how a public API changed. It also sets rules for prerelease and build labels. Release checks: Check the runtime and version, integration limits, dependencies and licenses, and platform support. Verify security, failure, speed, monitoring, deploy, support owner, upgrade path, and rollback. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.