Understanding Semver
In this blog post we’ll take a look at versioning. More particular we’ll understand what semantic versioning is, what it means for the user and the developer and how you should use it for your Meteor projects.
This is a free sample taken from “Auditing Meteor applications”
Introduction
It’s important to understand and stick to a specific versioning scheme. Especially developers rely on this versioning when they use e.g. packages developed by you.
Meteor uses semver as the primarily versioning scheme. This versioning is not just for beauty sake, it also speaks a clear language to the developer and Meteor itself (e.g. when dealing with packages).
How server works
(Major).(Minor).(Patch)<br />Major → Incompatible API changes
Minor → Added functionality in a backwards-compatible manner
Patch -> Backwards compatible fixes (such as bug fixes)
Examples from a developers perspective
Let’s say we have a package which has the version number 1.1.3.
If you e.g. update your package and fix a minor bug which does not directly affect the functionality of the package you simply increment the Patch number:
1.1.3 → 1.1.4
If you add another functionality which does not break the package API but is not a bugfix you’ll increment the Minor number. Furthermore you set the Patch number to 0:
1.1.3 → 1.2.0
The Major part needs to be updated when a breaking change of the packages API was implemented. The Minor and Patch numbers are set to 0 when the Major number is incremented:
1.1.3 → 2.0.0
This is not that hard to understand. Remember that other users and developers are dependent on your versioning because it tells them if package updates will break their app.
Examples from a users perspective
Let’s pretend we have a package installed with version number 0.1.2 and want to update it.
The new package version number is 0.1.8 → No problem. The changes might be just bug fixes.
The new package version number is 0.2.4 → No problem (although you should test it before deploying).
The new package version number is 1.0.0 → There might be a problem because of breaking API changes (Test intensively).
Of course you should always test the usage of the new package version before deploying.
Why semver matters
Semver is just a convention. You can define version number the way you want it to be.
However other developers and Meteor itself relies on correct semver usage as it shows you if something might break or if you can expect newly added functionality. Please always follow this convention if you’re a package maintainer!
