Semantic Versioning Lightning Talk
-
Upload
aaron-blythe -
Category
Technology
-
view
263 -
download
0
description
Transcript of Semantic Versioning Lightning Talk
Semantic Versioning
Aaron Blythe
Fundamentals – The Shot
Fundamentals – The Shot
Fundamentals – The Shot
Fundamentals – The Shot
Fundamentals – The Shot
http://semver.org/
Public API
• MUST declare a public API– declared in the code itself or exist strictly in
documentation– should be precise and comprehensive
• Once released, the contents MUST NOT be modified
• Any modifications must be released as a new version
Version 1.2.3
Version 1.2.3
Major Minor Fix (Patch)
Fix
Version 1.2.3
Version 1.2.4
Passive Addition of Functionality
Version 1.2.3
Version 1.3.0
Non-Passive Change
Version 1.2.3
Version 2.0.0
What about Continuous Integration?
• I build code everyday that is changing…
• Pre-release MAY be denoted by arbitrary string following the patch version and a dash
• Only alphanumerics plus dash [0-9A-Za-z-] • Precedence SHOULD be determined by
lexicographic ASCII sort order.
What about Continuous Integration?
1.0.0-alpha1 < 1.0.0-beta1 < 1.0.0-beta2 < 1.0.0-rc1 < 1.0.0
But every system is different
• Java Maven– 2.4-SNAPSHOT Builds: – server-2.4-20130917.071310-55.jar
• RubyGems– Rails• 2.3.8.pre1• 3.0.0.beta2 • 3.2.14.rc2
What about early on when I change the API everyday
• Major version zero (0.y.z) is for initial development.
• Anything may change at any time.• The public API should not be considered
stable.
When do I ship 1.0.0?
• If your code is in a production system, then it is a 1.0.0
What if I mess up?
Why is this important?
This is communication Mechanism
Why is this important?
Why is this important?