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

You can also add build metadata

1.0.0-beta

1.0.0-sha.b38f92e

A few key takeaways

Check your dependency versions into Git (package.json, Gemfile.lock, etc.)

Be careful of using packages that are on very high major version numbers

Be a good citizen and use SemVer as much as possible 😄

Responsible developers

=

happy dev communities

More info: semver.org

Semantic Versioning

By Denise Yu

Semantic Versioning

A crash course on SemVer -- what & why.

  • 1,771