MiguelSolano.US

SDLC #1: Semantic Versioning

29 May 2019

In Software Management, there exists a problem known as dependency hell. If you do your homework and build a piece of software that is successful and gain traction in whatever market you are in, chances are you’ll start relying on 3rd party dependencies. Although there may be reasons to avoid 3rd party dependencies, most of us can agree that it is simply not realistic to assume you’ll build a completely contained system, where your team writes all the code.

That being said, you’ll have to adopt dependencies sooner or later, and its in adopting 3rd party dependencies that we potentially create an issue for ourselves.

The two variants of dependency hell are known as version lock and version promiscuity.


Version Lock

Version Lock is typically caused by being too pessimisstic about your dependencies. Dependencies are usually declared with a strict reliance on specific versions and are often declared in a way in which an update to one dependency will require an update to all dependencies.


Version Promiscuity

Version Promiscuity on the other hand is a result of being too optimistic with dependencies. Which means any update to any of the dependencies may cause breaking changes.

As with most things in the software development world, a solution to this problem was found through emergent design. That solution is known as Semantic Versioning, or what we engineers like to call it SemVer. SemVer is a simple system for defining how to release your software and what your verisons actually mean. So how does it work?


SEMVER SPEC

SemVer operates with three main numbers detailing a release: Major.Minor.Patch (ex. 1.1.2 ):

  1. MAJOR - This number is reserved only for changes that make incompatible API changes.
  2. MINOR - This number is reserved only for changes that add functionality in a backwards compatible manner.
  3. PATCH - This number is reserved only for changes that make backwards compatbile bug fixes.

Some Rules For SemVer

There are some rules for SemVer that you need to keep in mind though:

  1. Software using SemVer must declare a public API, regardless, of whether its open or closed source.
  2. A normal version must take the form of X.Y.Z
  3. Once a version is release, it can never be modified.
  4. Initial version of a package must always be 0.x.x, and at this point it must be assumed that a public API has not been declared until version 1.x.x is released.

That’s SemVer in a nutshell.

If you’re wondering why its even useful to know any of this, then I would jump into any project that you are currently working on and inspect the package manager’s dependency file. You’ll find that more than likely you are relying on 3rd party dependencies and it’s important for the stability of your project to understand how you are declaring those dependencies.

Until next time! Cheers.