DEVOPS / A CONCEPT NOTE
Semantic Versioning
what 2.1.3 promises
Overview · mechanism
pitfall · examples
01 / THE SHORT VERSION
The idea in a few sentences.
A standard formatting rule for code releases: MAJOR.MINOR.PATCH. Increment MAJOR for breaking changes, MINOR for features, and PATCH for backward-compatible bug fixes.
02 / FOLLOW THE MECHANISM
How version resolution flows
Bug Fix
developer patches a security bug, incrementing PATCH: v1.0.1.
New Feature
adds a new endpoint (backward compatible), incrementing MINOR: v1.1.0.
Breaking Change
wipes out legacy API support, incrementing MAJOR: v2.0.0.
Client resolve
clients download updates safely using version ranges (~ or ^) matching their requirements.
04 / COMMAND NOTES
Read the command, then the result.
Inspect the flags and arguments before trying an example. Snippets can need local setup, replacement values, or resources in your own environment.
check if a version fits within range constraints
npm semver v2.1.3publish a SemVer tag to git repository history
git tag -a v2.0.0 -m "breaking release"05 / CHECK YOURSELF
Could you explain Semantic Versioning to a teammate?
Try it out loud in two sentences: what it is, and the one detail that changes the picture. If you stall, the gap is the part to reread.
Up next in Delivery & operationsRollbacksundoing a bad release