At work, my main job is to contribute to a Front-end component library that other teams in our company consumes.
Our team uses Semantic Versioning to organise our releases.
So what exactly is Semantic Versioning?
TL;DR Semantic Versioning is following a specific release format where the releases follow a Major.Minor.Patch format.
The definition of each vary slightly from company to company, project to project so the following is how I have learned to apply Semantic Versioning.
Why use Semantic Versioning?
Without Semantic Versioning, releases can result in confusion. For instance what does an upgrade from version 10 to 11 mean? Sure you can look through release notes, but can I be confident that I can make this change without much code changes on my part? If I upgrade then change my mind and want to downgrade, is this possible? Without a coherent and consistent spec users are left confused and uncertain about the upgrades they make.
Who uses Semantic Versioning?
Well if you use a popular package manager like NPM, Nuget or RVM you are probably already a consumer and beneficiary of Semantic Versioning whether you knew it or not. If your an NPM user have a check in your package.json and you will see that every package is a semantic versioning package!
In a way a cornerstone of effective packages is good semantic versioning practices. Ofcourse, just because Semantic versioning numbers are applied does not mean that the same quality and consistency exists for all packages. But you will find that popular packages will by in large take a consistent approach to ensure that Semantic Versioning is exactly as it was meant to be.
Considerations when working with Semantic Versioning
- Depends on your discipline: Remember without your careful thought process, Semantic Versioning is just numbers at the end of the day. The quality of ensuring that the release numbers mean what they imply they are depends on you.
- Planning: Working with Semantic versioning requires careful thought before starting a task what category change is being done. At work this is one of the first things I consider when I pick up a task. Sometimes it is also
- Branching Strategy: I can’t speak for other companies and teams, but our team has organised our branching strategy around Semantic Versioning. We have a branch for Major, Minor and Patch, and when a release takes place we make sure that more branches are synched in an ascending order Patch -> Minor -> Major.
- Things can go wrong: We can try our best but sometimes for whatever reason we may get the reasoning wrong. If we are lucky we may discover it before the changes are merged in. For example recently I made a number of commits in Minor before realising that the API would be changing. I was able to easily resolve this by git ‘Cherry Picking’ the changes and merging this into the Breaking Changes branch instead.
- Things can go very wrong: If we are less lucky we may merge in the changes to the wrong branch and make a release that affects end users. For example, recently we had a situation where a npm dependency was updated which in turn required a different global dependency from users. We didn’t realise this until a patch release had been made. Sometimes innocuous changes can be quite significant, as it was in this case and the best thing you can do is to learn from it and try avoid it next time.
Some resources to learn more about Semantic Versioning
