Semantic Versioning Lightning talk from the http://www.meetup.com/DevOps-Kansas-City/ September meetup.

1. Semantic Versioning
Aaron Blythe

5. Fundamentals – The Shot

6. Fundamentals – The Shot

7. Fundamentals – The Shot

8. Fundamentals – The Shot

9. Fundamentals – The Shot

10. http://semver.org/

11. 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

12. Version 1.2.3

13. Version 1.2.3
Major Minor Fix (Patch)

14. Fix
Version 1.2.3
Version 1.2.4

15. Passive Addition of Functionality
Version 1.2.3
Version 1.3.0

16. Non-Passive Change
Version 1.2.3
Version 2.0.0

17. 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.

18. What about Continuous Integration?
1.0.0-alpha1 < 1.0.0-beta1 <
1.0.0-beta2 < 1.0.0-rc1 < 1.0.0

19. 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

20. 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.

21. When do I ship 1.0.0?
• If your code is in a production system, then it
is a 1.0.0

22. What if I mess up?

24. Why is this important?
This is communication Mechanism

25. Why is this important?

26. Why is this important?