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