Software versioning controlled

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?

Our product

The architecture of our product consists of a JavaScript front end, a RESTful API and a SQL database. Our development team is split into 2 with the front-end being developed by different programmers to the back-end API and database.

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 1.3.0.0 – with independent front end and backend version numbers. So, for example, release 1.3.0.0 could be made up of front-end 2.6.1.3 and API 4.1.0.0. 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.

A solution?

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.

Leave a Reply

Your email address will not be published. Required fields are marked *