We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Core Fundamentals
Free preview: the first 2 parts of this 6-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 Core Fundamentals
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
March 2016. A developer named Azer Koçulu unpublished a tiny npm package called left-pad. It was 11 lines of code. It padded strings with spaces on the left side. Boring stuff.
Except thousands of packages depended on it. And many of those packages specified their dependency as ^1.0.0, which, in the world of semantic versioning, means "give me any version that's compatible with 1.0.0." When left-pad disappeared and was later republished with changes, builds broke across the entire JavaScript system. React, Babel, thousands of projects, all broken.
The chaos wasn't just because a package was removed. It was because the entire dependency system relies on version numbers meaning something specific. When you see 2.4.1, that's not arbitrary. Each number communicates something about what changed and whether it's safe to upgrade.
Semantic versioning is the contract that makes modern software dependencies work. Every time you run npm install or pip install or go get, the package manager is reading version numbers and making decisions based on their meaning. If those numbers lie, things break.
Semantic versioning, usually called semver, follows one simple format:
MAJOR.MINOR.PATCH
That's it. Three numbers separated by dots. But each one has a very specific meaning.
1.4.2 → 1.4.3
Something was broken, and now it's fixed. No new features. No changed behavior. If you were using 1.4.2 and everything worked, upgrading to 1.4.3 should be completely safe. Nothing you depend on changed, something that was wrong is now right.
Examples: fixing a crash, correcting a typo in an error message, patching a security vulnerability.
1.4.3 → 1.5.0
New stuff was added, but nothing existing was broken. Your code that worked with 1.4.3 will still work with 1.5.0. You just have access to new features you didn't before.
Notice: when the minor version bumps, the patch resets to 0. Always.
Examples: adding a new API endpoint, adding a new optional parameter to an existing function, adding support for a new file format.
1.5.0 →
It is easy and good
“It is really nice and good Please join the course”
2.0.0Something changed in a way that might break your existing code. Maybe a function was renamed. Maybe a parameter was removed. Maybe the response format changed. You cannot blindly upgrade, you need to read the changelog and potentially update your code.
When the major version bumps, minor and patch both reset to 0.
Examples: removing a deprecated function, changing the return type of a method, restructuring the API response format.
| Version Change | What It Means | Safe to Auto-Upgrade? |
|---|---|---|
1.4.2 → 1.4.3 | Bug fix | Yes |
1.4.3 → 1.5.0 | New feature, backward compatible | Yes |
1.5.0 → 2.0.0 | Breaking change | No, read the changelog first |