While we work on our SaaS product we’ve hit upon a versioning conundrum. What is the correct protocol for versioning the independent elements of a multi tier system?
This has led to a mixup around version numbers (not helped by developers not following the original rules we set out – grrrr!).
Initial numbering scheme
Our original idea was to have a release version – say 126.96.36.199 – with independent front end and backend version numbers. So, for example, release 188.8.131.52 could be made up of front-end 184.108.40.206 and API 220.127.116.11. We would record this in our release documentation.
I’m sure anyone reading this can immediately see where things might start getting confusing!
It worked well for the first couple of versions. Everything was pretty much in sync and the closeness of the numbers meant we felt in control. However as the numbers started to stretch apart, things have got very confusing.
Researching for standards
When I looked online for some guidance on this, there was very little that helped. Many people suggested using the standard semantic versioning rules of https://semver.org which we had already adopted. I did also read about a comment that it was a bad system, which I’ve written about. However, I could find very little advice on how to coordinate versioning of two independent application builds, plus a database.
I realised that if we used an automated build process, like a nightly build, we’d have a new version number across the board every day. That’s not the way we work.
However, with that idea in mind and my Agile hat on, I hit on a plan. Using the Agile definition of ‘Done’, I would assign a version number when we arrived at Done for the sprint. I wouldn’t depend on the front-end or the back-end for a version number, or document two sub numbers into a single version. I would take control of the release version.
So, when we get to a point where we are Done, I look at the previous release and make an informed decision about whether this version is a major or a minor change, or patch across the full architecture. I then distribute this version number which is used by both teams to tag their builds.
This means that we have a moment in time where all components work together, are built together and have a consistent version number. Even if we get to a release and no API changes have taken place, a new build of the API with that version number will be created.
Is this the best way? Only time will tell. We are about to start on this method, so only after a few versions will we know if this is proving successful.
Is there a standard that I haven’t come across for this very issue? I haven’t found anything to suggest there is, so I’ve taken this into my own project management hands. Hopefully the confusion will subside as we move on.
Other versioning ideas
We did briefly discuss other versioning systems – animals, sweets or cake types – but this soon became ridiculous. We do get carried away with the absurd in our office! Battenburg 2.0 does have a certain charm though.