Semantic Versioning Cheat Sheet

The MAJOR.MINOR.PATCH semantic versioning specification for communicating compatibility in software releases.

1 PageBeginnerFeb 12, 2026

Version Format

The three-part core version number and what changes to each part signal.

MAJOR- Incremented for incompatible/breaking API changes, e.g. 1.x.x to 2.0.0
MINOR- Incremented for backward-compatible new functionality, e.g. 1.2.x to 1.3.0
PATCH- Incremented for backward-compatible bug fixes, e.g. 1.2.3 to 1.2.4
Initial development- 0.y.z means anything may change at any time; the public API should not be considered stable

Version Examples

Reading real version strings against the spec.

text

1.0.0        # First stable public release1.1.0        # Added new backward-compatible feature1.1.1        # Bug fix, no new features2.0.0        # Breaking change, e.g. removed/renamed an API1.0.0-alpha  # Pre-release, lower precedence than 1.0.01.0.0+20260708  # Build metadata, ignored when comparing precedence

npm/semver Range Operators

Common range syntax used in package.json dependencies.

json

{  "dependencies": {    "lodash": "^4.17.21",       "express": "~4.18.0",       "react": "18.2.0",          "typescript": ">=5.0.0 <6.0.0"  }}

Range Operator Meaning

What each caret/tilde operator actually allows.

^ (caret)- Allows changes that do not modify the leftmost non-zero digit, e.g. ^4.17.21 allows 4.x.x but not 5.0.0
~ (tilde)- Allows patch-level changes only, e.g. ~4.18.0 allows 4.18.x but not 4.19.0
Exact pin- No operator means only that exact version is accepted
Pre-release precedence- 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta < 1.0.0

Pro Tip

A breaking change is defined by your public API contract, not your intent — removing a field from a JSON response or changing default behavior counts as MAJOR even if you consider it 'just a fix', because it can break consumers silently.

Was this cheat sheet helpful?

Git Branching Strategies (GitFlow/Trunk-based) Cheat Sheet

Package Managers Comparison Cheat Sheet