Until now, the marketing version of my apps was set using Semantic versioning as my Software versioning scheme. I did that out of habit and without seriously thinking about it.

But Tom Preston-Werner invented Semantic Versioning with a purpose: avoiding the dreaded place called "dependency hell.". And thus, it measures significance based on risk and functionality.

I now think that this scheme is inappropriate for the App Store and, even worse, that it can get in the way of what it takes to create a great app.

Risk and functionality are poor criteria

Users can't choose which version they install from the App Store, so the notion of accounting/risk is out. So, we're left with functionality.

It's simple on the surface:

• big update: increment the major number,
• small update: increment the minor number,
• bugfix: increment the patch number.

But what characterizes a "big update"?

The appreciation of what constitutes a big update is personal. You only have to see the reactions when macOS or iOS versions change to realize that it is not easy to be worthy of this label. How many new features does it take to be worthy of being "big"?

Moreover, creating a quality application requires that you spend time on minute details that make it more enjoyable but may not be obvious, if not downright invisible, such as making the app more reliable, more efficient, more accessible or better organized to prepare for future evolutions.

Not changing the major number can give the impression that the application is stagnant.

Of course, I can decide to change this number more often and explain my motivation in the release notes, but this implies having to ask the question at each release: is this a significant update?
And what happens if I spread it over several updates to evolve things gradually? Should I increase the number at the beginning of the changes, in the middle, or at the end?

This pushes us to make significant updates, including a lot of changes at once (and therefore a lot of bugs, I'm not aiming at anyone…), rather than making the application evolve quietly, taking advantage of user feedback, and minimizing the damage.

Moreover, distinguishing what is major from what is minor doesn't really make sense on the App Store. For a user who is behind on updates, an update that is considered "minor" to you may in fact be a "major" update to them because it includes one or more missed "major" releases.

Finally, I want to love "patch updates" and not be ashamed of them. When someone reports a bug, I always put aside the fun work to get the fixes out as quickly as possible and relieve the affected users.
This is a good thing, I think it's part of what makes an application great, and yet it increments a number that may disappear afterward leaving no trace.

It's time for a change.

Which scheme is better then?

I want my numbering system to reflect my ongoing effort to improve the application, which means that it should give an idea of:

• the release's age: an anchor in time
• the update frequency: a measure of my effort

But, is the year the right time component?

What other options do we have:

• going to decade or century makes little sense
• using the month gives a format where there is confusion about the meaning of the last digit: is it the day or the month increment?
• using the day would hide the effort component, but also the delays of publication on the App Store make it less intelligible

So yes, the year feels just right to me.

Is anyone else doing it already?

I am hardly the first to have this kind of thinking.

Up until now I had ignored it and thought of it more as a personal choice. But this feeling of guilt linked to the gap between the effort and the evolution of the version number started to weigh on me recently, and I finally made the connection.

This system has been adopted by other applications already, such as Slopes (Curtis Herbert may even have been the first) or Crouton by Devin.

I want to be at peace while I do my best to do great work. I want users to feel that the application they enjoy is well-taken care of. I want to enjoy my work without chasing milestones that don't make sense.

That's why I am joining the movement, and No Meat Today jumped from version 4.23 to version 2022.27.

We can talk about it here: