Semantic Version Numbering for Apps?

Just a quick question about version numbering for apps. Are there plans to allow us to follow the semantic numbering standard? For those unfamiliar with this, if you have app version X.Y.Z.A, X is the major version, Y is a minor update, Z is a patch, and A is anything less than a patch. Let’s say you release version 1 of your app, but you discover you made a grammatical error in an alert or you have one block of code that is not working exactly as expected in the live environment (I mean, we can only test so many variables, right?), so you want to update it. The way Thunkable works now, I have no choice but to release version 2; but, it’s not really a version 2. In this case, it should be either version 1.1.0, 1.0.1, or 1.0.0.1, depending on how you wish to classify the update. If you try this now with Thunkable, this is what you get (at least on iOS; I haven’t tested on Android yet):

I have also tried X.Y.Z (6.1.0) and it gives the same error. I think this would be an important aspect of developing on Thunkable. As Android and iOS versions change and apps need to be made compliant with new innovations and standards, an app does not always need to be a major version update. Minor tweaks to the operating systems could mean our apps need to be republished using new builds, but this could certainly mean that version 1.0.0 could be updated to 1.1.0 to match these requirements instead of jumping to version 2 which adds no new functionality to the app.

This came to mind after my recent publish with IAP where I went to version 5 (really should be version 2.4.0 or, possibly 3.0.0) and a bug that wasn’t occurring in testing popped up in the wild. Instead of being able to push a version 5.1.0, it had to go to 6.

Just a thought I wanted to see if anyone else has been considering. I searched the topics and didn’t really find much on semantic numbering.

3 Likes