SemVer in production – always keep separate production branch on its own minor

While I personally prefer CalVer, SemVer is still actively used for many projects and quite frequently I work on it.

If SemVer is used for something that is deployed to production, one rule I’ve made is to always keep each distinct production on its own minor version. If we have only one production environment or each production environment uses same version of this software – we’re lucky and we can use just one separate branch with dedicated minor. If production environments are way too different, then multiple branches, each on its own dedicated minor might be needed.

Why is this required?

Simple example – let’s say we have a version 1.2.2 deployed to production. And let’s say we need to make a tiny fix there. Natural choice would be to make a 1.2.3 patch and deploy. Now, if we use 1.2.x versioning elsewhere – we’re in a big trouble. Because we might already have 1.2.3 and potentially we have a lot more – 1.2.4, 1.2.5, etc -you name it.

So if we’re in a later case and even if we followed SemVer conventions and all those patches are forward and backward compatible, we have to spend a lot of time on testing and making sure that our latest 1.2.x build doesn’t break production – and only then can put a new patch on top of that and deploy. This whole process can be very costly time-wise.

The only solution I see out of this – dedicate 1.2.x versioning solely to production, and make sure that every patch created there is destined to production right away. At the same time, have all current or future development in 1.3.x or later minors or majors. I believe this is the safest way to maintain clean production update strategy.