Running Track's beta version number is now meaningfully meaningless

I don't really care about version numbers

I've long thought that version numbers are unimportant. The Semantic Versioning structure of major.minor.patch is useful for shared code like libraries and frameworks, but for a client application, while it's still common, it's overkill. Who benefits from knowing if you're on v1.2.3 or v6.9 or v12.0? Famously Google Chrome doesn't bother with Semantic Versioning. Every release is just a new number and it's gone past version 100 now.

The version name is useful of course. It's meaningful for customer support, so that you know if a bug has been patched already, or a feature released, and in which version. It's useful for feature flagging, if you only enable certain features on certain app versions. But that can be any version number, it doesn't have to be x.y.z.

Setting version numbers is harder than it sounds

If you follow Semantic Versioning, you have to spend time deciding on what makes you go from v1.x.x to v2.0. What changes count as major or minor in a client application? And what's the marketing impact of that?

I've worked in companies that shipped code as a major change to the version number, but because everything was feature flagged off, we couldn't talk about the changes. So going from v1 to v2 of an app looked like a damp squib. Marketing didn't like that.

I've worked in teams that have spent hours discussing whether a version should be a major update or a minor update. Hours. People have opinions! I'd much rather remove opinions from the equation.

My initial solution for Running Track

Ubuntu, as well as plenty of other projects now, uses year and month in release names, such as 22.10. That format appeals to me, because it makes it easy to set without any discussion.

Automating the changing of release names also speaks to me. It's nice not to have to think about about these things. Just build the app, and the version gets set based on the current date, without having to think about it.

I had that set up for Running Track. The build I had approved for TestFlight was 22.11.17, because that's the date on which I compiled the build. It matches my approach for automating tagging of builds in git, which seemed useful.

You may have already spotted my mistake...

Testing builds need to be reviewed for TestFlight whenever the version changes. However if you do a new build for the same version name, you don't need another review. So if I make a new app version when the day changes, I'll need to go through TestFlight review again, every day I submit a build. Not appealing!

Meaningfully meaningless

So I've got rid of the automation and I'll be setting the version manually for now. While Running Track is in beta, I'll just keep that random version name. So every beta tester will know when the first build was cut. Meaningless, but with a hidden meaning. Kind of fun, no? Then I'll move to a year.month format like 23.1 in future.

Top tip: don't get too clever and automate too much too soon!