PaceVer (an alternative to SemVer, for mobile apps)
29 points by pvinis
29 points by pvinis
I just published this. Feel free to ask any questions, and I'll try to answer! This has been something I do for a while unofficially, so I decided I'll make it more official for others to see/use.
The first number being reserved for marketing fits my experience pretty well. Might as well make it official.
There's two parts I'm wondering, one is that I don't think mobile users actually care about versions compared to desktop / libraries? Lots of big name apps have indecipherable app versions (Play / com.android.vending is a great example with Version 51.6.23-31 [0] [PR] 922927408, Orwell would shed a tear)
If your team wants to signal that a release is a big deal, that signal goes in MARKETING, which is yours to spend however you like.
implies to me that users are supposed to care, when you'd realistically do annoying modals announcing how cool your redesign / rewrite / release is.
The other part is that version is something part of the app manifest (for Android), you'd need to distribute a new binary anyway, unless you forego it in sake of a in-app version (which means you have two sources of conflicting truth now)
I don't remember who did it like this (I can only think of Discord right now), but I think it's probably more useful to version the JS in-app separately from the native app since you can't display a secondary OTA version within system settings / app manifests.
Very good point for the first one. Users indeed don't care much, and that is exactly why I made this. This is great and very useful for devs of these apps. They immediately know from the three numbers what was the way the update happened that, say, broke a feature. Also users do sometimes care, and that's the first big number, the marketing one, so you can have your CoolApp v4 introduction and blogpost and all that for your users that do care. :)
About the second one, I do have the second bullet on https://pacever.org/#why, which is exactly that. The stores (and also native code) will know the x.y.0 bit. The last number will only be for the OTAs. I have found this extremely useful working with git history, with sentry, posthog, and anything else connected, because they can get the full version, while yes, maybe the appstore and playstore analytics might be stuck on the .0 version. They would not know your OTA number anyway, no matter how you keep it in the app.
This is great and very useful for devs of these apps. They immediately know from the three numbers what was the way the update happened that, say, broke a feature. Also users do sometimes care, and that's the first big number, the marketing one, so you can have your CoolApp v4 introduction and blogpost and all that for your users that do care. :)
I might be writing this with the more corporate world of apps in mind (like Play), I imagine the further you move away from it, the more users care and then this versioning scheme is otherwise fine.
Sorry for the cynicism, admittedly I might just be upset about things like lack of change logs for apps and that might have bled into my judgement a little.
Very fair. I agree with you. I try to keep good changelogs and show them on any app I work on :)
I really don't see the benefit and don't understand why I should use this instead of semver. And OTA Updates is still a regular update, right? And defining a marketing number that I can bump how ever seems odd. This somehow negates the value of versioning
This is for mobile apps. There’s very little compatibility with other software in that space. So there’s no point focusing on it. Main “consumers” of versions there are end users. They use the version to identify software when reporting issues. Likewise, the dev can communicate “big” changes by bumping the first numbers, the “major” version. A redesign that shuffles things around is sort of a compatibility issue as people would need to learn the new UI. It doesn’t break anything in the SemVer sense but still.
SemVer is mostly targeted at libraries. Its main concern is API compatibility.
These are two very different contexts. Versions have very different meanings in them. It makes sense to use different versioning schemes.
I can see the marketing number being useful in a comparison between the following two changelogs
Without marketing levelVersion 8439.1 is, from a semver perspective, a "minor" release, but it has a far large impact on my operations that most of the "major" releases. Marking this version as 7.0 makes that impact more readily evident. Adding a channel for this information could be useful, though it likely should not be left to the marketing department.
I loled at the "not let to the marketing dep"! Yes, I couldn't find a better name for this. "Human"? "Era"? I went for "Marketing" which is to say that the devs or PMs would chose when to bump that number, so that the users can see a "marketing" thing (ad, blogpost, banner, whatever). It's basically as you say it!
It's fairly common in live-service games to have the data for the game, which defines units and maps and so on, downloaded via the game itself, separate from whatever mechanism distributes the underlying game binaries. The code itself only gets updated when there's something that needs a code change. I assume one of the big upsides of this is that the former requires far less coordination with the platforms.