I wonder about version numbers - specifically, what way of versioning apps (or other, mostly user-facing software) is really sensible.
There are several approaches to this problem in general, one of which is Semantic Versioning (SemVer):
This versioning scheme strictly doesn't apply to most apps, though, because those don't really have a "public API". One might be tempted to use this scheme anyway, because so much of it makes sense - but then it becomes necessary to define what an app's analogue to a "public API" is, and what exactly constitutes a "backwards incompatible change" to it.
In the past, I tried to mimic versioning schemes I saw elsewhere, but those are really all over the place as well. Take Google, for example: big company with all sorts of app, if anyone has a clue what might work and what doesn't, it's probably them. However, when I checked version numbers of Google apps installed on my phone right now, I found at least fifteen(!) different versioning schemes and stopped counting at that point. Here's an annotated list:
Having one number is the most simple approach. In this case, the number could be the date (September 6, 2018) of finalizing this app version, perhaps combined with a counter (24th release?).
MAJOR.MINOR is often seen in version numbers. For this versioning scheme to be sensible, it needs to be defined what exactly constitutes a "major release" vs. a "minor release".
MAJOR.MINOR.PATCH is another scheme used often, and also suggested by Semantic Versioning. As mentioned above, it is unclear how exactly SemVer applies to apps that don't come with any "public API", so this needs to be interpreted differently.
Four or five numbers:
If more than three numbers are necessary for a version number, the fourth and fifth numbers are sometimes called BUILD or REVISION. In the above cases, the individual numbers must have different meanings - for example, the second version number has a 4-digit number in its third position (build number?), whereas the third one ends in an 8-digit number (release date again?). There's also some potentially meaningful variation in separator (dot vs. dash) and in whether numbers have a fixed length or not (some start with a leading zero).
More than just numbers:
Last but not least, there's a whole range of version numbers that include additional information in the form of strings or parenthesis:
- "release" or "RC##" ("release candidate") is sometimes used to identify app versions that are meant for the public (vs. "alpha", "beta", "canary", ... for internal testing)
- "DR49" seems to be a repeat of the first number ("Duo Release 49"?).
- "armeabi-v7a" is a reference to specific hardware that is supported by this app version
- several of the version numbers use a 9-digit number in a similar range (213... - 236...). I assume that this might either a date/time representation standardized across Google, or something like a reference for the most recent commit to Google's monolithic code repository (link below).
<END OF LIST>
The conclusion to draw here is that it either makes sense to have more than a dozen numbering schemes going on at the same time - probably depending on what exactly an app does and needs - or that Google's developers are just as clueless as the rest of us when it comes to versioning.
Something worth noting here is that all of these versioning schemes and their resulting version strings are not necessary for your phone to work, or your app store to update your apps properly. This is because all of these version strings are considered to be just "names" by the app store. They are shown to users, but are never used to decide whether the app installation on your phone needs to be updated. Instead, there's a separate variable called a "version code" that is used for this purpose. The version code is a single integer number that monotonically increases over time - and if the version code of your app installation is smaller than that of a compatible version available via the app store, the app gets updated on your device.
This leaves two main functions that a version number should fulfill. It should be sensible to end users that see it, and informative to developers that receive bug reports with that number. The only requirement for the latter is that version numbers are unique (and perhaps that misspelling one doesn't lead to a valid other).
What sensible versioning schemes do you use, or can you think of - and why?