We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Devops Cicd
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Devops Cicd
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
A library published version 2.3.1 that changed the return type of a core function. Every application using that library broke on their next npm install. The library maintainers thought it was a minor change. The application developers disagreed. It was a breaking change that should have been version 3.0.0.
This is not hypothetical. In 2023, a Babel plugin released a patch version with a breaking TypeScript change. Thousands of CI pipelines broke overnight. The issue sparked a 200-comment GitHub thread about semver discipline. The fix? Revert the patch, re-release as a major bump.
Semantic versioning (semver) exists to prevent this miscommunication. It's a contract between package authors and consumers: the version number tells you what kind of change to expect before you install it.
| Component | Incremented When | Example |
|---|---|---|
| MAJOR (X.0.0) | Breaking changes. Existing code may stop working. | Removing a function, changing return types, restructuring API |
| MINOR (0.X.0) | New features, backward compatible | Adding a new endpoint, new optional parameter |
| PATCH (0.0.X) | Bug fixes, backward compatible | Fixing a calculation error, patching a security vulnerability |
2.3.1 means: 2 breaking changes since 1.0.0, 3 feature additions since 2.0.0, 1 bug fix since 2.3.0.
Pre-release versions: 1.0.0-beta.1, 2.0.0-rc.1 indicate versions not yet stable.
Git tags: When you release version 2.3.1, tag the commit: git tag v2.3.1. This creates a permanent reference to the exact commit that represents that version. pipelines can trigger on tags to build and publish releases.
Version ranges in package managers:
| Range Syntax | Accepts | Example |
|---|---|---|
^2.3.0 (caret) | Same major, any minor/patch | 2.3.0 to 2.99.99 |
~2.3.0 (tilde) | Same major.minor, any patch | 2.3.0 to 2.3.99 |
2.3.0 (exact) | Only that exact version | 2.3.0 only |
>=2.3.0 <3.0.0 | Explicit range | 2.3.0 to 2.99.99 |
The caret (^) is the default in npm. It trusts that minor and patch updates will not break your code. This trust only works if package authors follow semver honestly.
It is easy and good
“It is really nice and good Please join the course”