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?