Semantic versioning: MAJOR.MINOR.PATCH
Almost all modern software uses semver. A version like 1.0.66 reads left to right: MAJOR.MINOR.PATCH. Each button above bumps a different segment and grows the 3D tree in a different direction — patches stack small twigs, minors branch sideways, majors start a whole new trunk.
| Bump | When | Example |
|---|---|---|
| PATCH (x.x.N) | Backward-compatible bug fixes only | 1.0.65 → 1.0.66 |
| MINOR (x.N.0) | New features, still backward-compatible | 1.0.66 → 1.1.0 |
| MAJOR (N.0.0) | Breaking changes; may require code updates | 1.1.0 → 2.0.0 |
So "v1.0.66 with 102 enhancements" is technically a patch line but bundles many small fixes and additions — common for fast-moving developer tools that release daily.
Decoding a release note
"Add support for X"
A new capability. If it's a feature (not a fix), strict semver would suggest a minor bump. Read these to know what's newly possible.
"Deprecate Y"
A warning: the feature still works but will be removed later. Deprecations are your notice to migrate before the next major version deletes it.
"Fix / prevent crash"
A bug fix. These are the safest updates to take immediately — they only remove broken behavior.
"Now accepts..."
An input or config change. Usually additive and safe, but check whether old formats still work.
Why versioning discipline matters
When a tool follows semver, you can automate upgrades safely. A dependency pinned as ^1.0.0 means "accept any 1.x.x" — you'll get features and fixes but never a breaking 2.0.0 without an explicit choice. This is the backbone of package managers (npm, pip, cargo). A worked example: if 1,000 projects depend on your CLI and you publish a breaking change as a patch instead of a major, you can silently break all 1,000 overnight. That's why disciplined deprecation-then-removal across major versions is a professional courtesy, not bureaucracy.