Version numbers and strings

[afischerdev]

One of the plans for the next versions is to set up a beta version on the Play Store to find more test users.

This requires a slightly different usage of version numbers.

Full production versions have a trailing zero, e.g. e.g. 1.7.0 Beta versions between 1.7.0 and 1.8.0 come with 1.7.1 and so on.

The versionCode variable is just a counter it could be changed to 10700 for production 10701 for beta ... So we have a better overview of what versionCode for the versionName.

Only the production versions get a git tag, so F-Droid releases only those.

What do you think?

[devemux86]

@afischerdev great idea, so more users can easily try the beta versions.

Do you mean the Open testing where users join the app's testing program? (Play Console Help)

You could also set the text "Beta" in the version name, so users know that they are using a beta version.

[afischerdev]

@devemux86

thanks for the idea This makes it clearer for users. And yes, I was thinking about open tests. Doesn't seem like too much work.

[zod]

I also suggested releasing beta versions of the app on the Play Store, so of course I support that suggestion.

I think we should stick to an established versioning scheme like SemVer. I think normally users a familiar that 1.7.1 is a patch to release 1.7 instead of a beta version. versionCode could still be inferred from version number similar to the scheme you suggested by tracking the beta release number in the least significant digit.

[afischerdev]

@zod Thanks for the suggestion. Seems to be usable when I look at the naming conventions.

With a new version '1.7.0' we are on the 'semver' path, we have minor changes for the api on board (I would transfer 'API conform' with our server/apk input rules).

But lets discuss some samples - starting with 1.7.0:

• next update goes for the Androd Ui, version 1.7.1 (no api changes) beta apks have now 1.7.1-beta-a, 1.7.1-beta-b, ... (for discussions in news groups) a beta in Play Store could be like 1.7.1-rc-1, 1.7.1-rc-2, ... (I would recommend not to much updates here and more stable versions)

  And what about the versionNumber for Android? 10701 was the next versionNumber analog to versionName (see above). For Android we need at least a +1 minimum for publishing. Would be 10702 for a release candiate 1.7.1-rc-1, 10703 for 1.7.1-rc-2, ... Seems we need more numbers like 1070100 to fit the 'semver' logic. That would bring 1070101 for '1.7.1-rc-1', 1070102 for '1.7.1-rc-2', ...

  This would end in a number e.g. of 1070147 for the release of 1.7.1 - here I would expect 1070100

  Or we just stay with the current versionNumber of 45 and increase that on every need?

• other sample, update add a new parameter for input (xyz=1 [0..5]) would bring next version to 1.8.0 - api changed a bit

  Looks like a great new thing but may be only 5 new lines in code, when you compare the work for the ui update not a heavy change.

[devemux86]

Or we just stay with the current versionNumber of 45 and increase that on every need?

:+1:

Although I have worked with both methods in the past, I now prefer this method as it seems much simpler.