Going from SemVer to CalVer
Lately I have been pondering over the idea of switching my products’ versioning scheme from the typical SemVer to CalVer. The reasons for doing so have to do with the way I prefer to develop and release software: incrementally. It is very common in SaaS products to ship incremental features and fixes instead of bundling every change in a single patch. I don’t think this methodology is wrong for desktop or mobile products.
If you think about SemVer and the workflow you adopt by adhering to it, having a patch component in the version number means that you should only fix issues in patch (or micro) releases, add backwards-compatible features in minor releases and leave major releases for breaking changes or big sets of changes. This works great for libraries, command line utilities and other Operating System components, but I don’t think this is good for consumer software. With every change I make to my products code bases, I need to think if these changes constitute fixes only, or if adding some minor change should go in a patch release along with fixes or in a minor release. This is not the way I like to develop and makes me nervous for some reason. I would be happier with a major.minor version scheme and increment the minor number with each release, without ever caring if the release contains only bug fixes or some minor feature. There are lots of software that are numbered like that.
But then I could just use year.release versioning scheme. It would make it quite clear if the software is being maintained by looking at the year part of the version. And every time I publish a release, I would only have to increase the release part. I think this scheme fits very well with the idea of incremental improvement and also makes it far easier to switch to the next version (the next year) without having to endure the long periods of development without releasing to bring new features to justify a major release.
There is no need for subscriptions (or there is?)
If you think about it, the aforementioned scheme is similar to how a subscription app is developed, but without the subscription part. In fact, this opens the possibility of maintenance payments, where the user purchases an upgrade to have access to the next year of releases, but she’s not obliged to do it and can keep on any previous version that still works.
How does this affect the user? I think this is positive for both the developer and the user. The user gets to own a version (say the 2021 version) that never expires, paid for only once. The developer keeps improving the 2021 version and when the next year arrives, the developer switches development to the new (2022) version. It’s up to the developer if users are upgraded for free or with a discount. There is a downside: the user has no way to know before hand if it will be worth it to upgrade to a release that has had almost no development when first released. But as also happens with upgrades between major versions, the user can decide to upgrade at a later date, there’s no rush.
How about the App Store? As the App Store has no way to do sensible paid upgrades, this of course doesn’t work very well. The only way is to publish a new product version and retire the old one. But there is another way, one most users and many developers prefer not to touch: subscriptions. Given that I sell my Mac apps both in the Mac App Store and directly, I guess I could switch the Mac App Store versions to be subscriptions. People who prefer to pay just once would purchase directly. The customer is in full control.