Versioning ? You’re doing it wrong.

frontyend
2 min readJan 6, 2016

Nowadays,keeping javascript libraries updated is become real pain in the ass.

Libraries changing and growing fast, they rarely do versioning right. I’m not even talking about documantation and testing that is a complete different story. Even a month old example code often becomes broken and you need to search over change logs to figure out what’s changed.

For the sake of stability, please make sure that you are doing versioning right.

Semantic Versioning

SemVer is very popular and the most misused software versioning scheme in javascript universe.

Yes! I said “misused”. Because many popular javascript libraries or let me correct it, many contributors of popular javascript libraries usually do not care or break the rules of the semantic versioning.

Ok, enough complaining and lets learn and do it right.

In systems with many dependencies, releasing new package versions can quickly become a nightmare. As a solution to this problem, SemVer proposes a simple set of rules and requirements that dictate how version numbers are assigned and incremented.

Given a version number MAJOR.MINOR.PATCH, increment the:

  • PATCH: Bug fixes and other minor changes: Patch release, increment the last number, e.g. 0.0.1
  • MINOR: New features which don’t break existing features: Minor release, increment the middle number, e.g. 0.1.0
  • MAJOR: Changes which break backwards compatibility: Major release, increment the first number, e.g. 1.0.0

Ps: All packages in npm have to follow the rules above.

It’s easy, right?

Next time you get a minor change in a package uses SemVer and breaks your code. Open a bug report and make them know what is broken and why.

--

--