Denise Yu
I'm a software engineer. You can usually find me at the local pub, bouldering, or hunting for the best Korean fried chicken in London.
Semantic Versioning
@deniseyu21
The problem
Developer #1
(Let's call her Kimberley)
Kimberley works on a big open-source platform
They release beta,
call it "Version 1"
Developer #2
(Let's call him Georgi)
Georgi is part of the Ruby core team
They release a patch to fix a major security flaw
Giuseppe calls it
"Version 2.2.5"
Developer #3
(Let's call Her Franzi)
Franzi fixes a bug in a popular JS library
HOWEVER
The JS library no longer works in Internet Explorer
She calls her new version,
😈
(just because She can)
What's the problem?
Other than the authors, nobody understands these versioning codes
2.2.5
Version 1
😈
?
?
?
?
Dependency hell
...[using] shared packages/libraries on which several other packages have dependencies but where they depend on different and incompatible versions of the shared packages
from Wikipedia:
Enter
Semantic
Versioning
1.2.3
Major
Patch
Minor
Major (1.0.0 => 2.0.0)
- Possibly not backward-compatible
- Expect API-breaking changes
- Version 0 is fast-changing, unstable beta
- Version 1 is stable public API
Minor (2.0.0 => 2.1.0)
- Probably backward-compatible
- Some old features may be deprecated
- Generally used when new features are added
Patch (2.1.5 => 2.1.6)
- Always backward-compatible within minor release
- Resets to 0 with every minor release
- Generally used for bug fixes, no new behaviors
You can also add build metadata
1.0.0-beta
1.0.0-sha.b38f92e
A few key takeaways
Check your dependency versions into Git (package.json, Gemfile.lock, etc.)
Be careful of using packages that are on very high major version numbers
Be a good citizen and use SemVer as much as possible 😄
Responsible developers
=
happy dev communities
More info: semver.org
Semantic Versioning
By Denise Yu
Semantic Versioning
A crash course on SemVer -- what & why.
