Semantic Versioning seems to be THE solution every time you talk about releasing software. At least in theory. Because practice is often a lot more complex. Let’s cover the basics and complexities in five minutes! - What is and isn’t covered by SemVer? - What’s the asymmetry in it? - What does the versioning schema of popular products like Kubernetes actually look like?

1. Did Anyone Say
SemVer?
Philipp Krenn @xeraa

2. MAJOR.MINOR.PATCH
aka break.add.fix
@xeraa

3. Lowest and Highest Version?
1.0.0-alpha.2 1.0.0-beta 1.0.0-alpha.11
1.0.0-alpha 1.0.0-alpha.beta
@xeraa

4. "You're doing
SemVer wrong"
https://xkcd.com/386/

5. What Is THE API?
REST, client, platform, "internals" —
it depends
@xeraa

6. What Is Breaking?
https://xkcd.com/1172/

7. "Experimental"?
yes or no
@xeraa

8. UI Changes?
yes or no
@xeraa

9. Avoid Version Ranges
Java
!
, npm
@xeraa

10. Before 1.0?
ZeroVer ==
@xeraa

11. Example: JDK <9
major.minor.security: 1.7.0_55 vs 1.7.0_60
@xeraa

12. Example: JDK 9+
release train, might have breaking changes
@xeraa

13. Example: Kubernetes
replacement, deprecate, roll forward, remove
https://kubernetes.io/docs/reference/using-api/deprecation-policy/
@xeraa

14. Example: Terraform
0.x and enterprise support?
https://github.com/hashicorp/terraform/issues/15839
@xeraa

15. Example: Ansible
not SemVer but mayhem
https://www.ansible.com/blog/ansible-3.0.0-qa
@xeraa

16. Example: MySQL
@xeraa

17. Alternative: CalVer
Ubuntu
@xeraa

18. Alternative:
Odd / Even
MongoDB < 5.0
node.js < 1.0
Linux 1.0 – 2.6.x

19. Alternative: Git Hash !
@xeraa

20. We're doing
SemVer