Background
I generally prefer Semantic Versioning (SemVer) to Calendar Versioning (CalVer) for software. I love that SemVer makes it easy to anticipate likely working/non-working updates to software! But there is a problem: SemVer doesn’t really give me a good picture of the “freshness” of updates. CalVer solves some of my frustrations with SemVer, but leaves me with other annoyances.
I have something better in mind, but I first should enumerate what I don’t like about both systems.
Problems with Semantic Versioning
If I compare two versions of some software, I want to be able to tell how badly I should upgrade. Consider version v1.0.0 to version v1.1.124. What do I currently know? According to SemVer, that new features were added in v1.1.0 that are backwards compatible and that there have been 124 “patch” builds of v1.1. According to SemVer, the patch level is just for bug fixes.
Does that patch level 124 mean that the software has literally had 124 bug fixes? Or have the developers used the patch level as a build number where they have done other work that isn’t bugfixing (and also isn’t new features). Other work meaning re-writing features, cleaning up old code, etc. I really don’t know. I’m left having to make assumptions as to whether the 124 is a patch level or build number.
Problems with Calendar Versioning
Calendar Versioning takes an alternate approach and says that SemVer is just arbitrary numbers. That knowing when software is released is more important than whether or not it has breaking changes in it. It suggests a good example to be Ubuntu, with the latest release being 21.10 (which was released Oct 2021). This seems to make sense if your softare will literally never have breaking changes. It certainly makes it easy to compare v19.04 and v21.10 to determine that the older version is about 2.5 years older than the newer one. But it definitely tells you nothing else about how much work has gone into the new releases and nothing about the possible breaking changes.
Something Better
Is there a single versioning system that is better than either or possibly both of these systems? Maybe not. But I’ll still take a stab at it anyway: Combined Versioning (ComVer)!
Combined Versioning would provide insights into the following ideas without anything besides the version numbers:
- Breaking changes
- Release dates
- Active development
Here’s how it would look:
- Major
- Year/Month
- Build
Any breaking changes must be accompnied with an increase to the major number. Any builds in a new month must increase the Year/Month number appropriately. And any new builds (you pick whether you only count internal builds or release builds) increase the build number.
Under a scheme like this, I could compare v1.2202.0 and v1.2203.124 and understand that the initial v1 release happened a month prior to the 2nd version number and that between these two versions, there have been 124 new builds and none of them have introduced any breaking changes to the software. Similarly, comparing v1.1904.1050 and v1.2203.1051 tells me that in almost 3 years, there has just been 1 new build completed. Maybe a bugfix/maintenance release or something. Still, it provides much more insight into how fresh the software is at a quick glance.
I’d imagine that you could optionally reset the build number between each major release if you’d like to. But definitely not a necessity either.
Wrapping Up
What do you think? Come tell me what you do or don’t like about such an idea.
When I get some feedback that tells me why this is a bad idea, I’ll be sure to come update this as well so that others may learn too.