Semantic Versioning


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


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


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:








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



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:

Semantic Versioning

By Denise Yu

Semantic Versioning

A crash course on SemVer -- what & why.

  • 1,790