In correspondence with @Catfriend1 he proposed to change the versioning scheme of the android app to more closely reflect the Syncthing versions. Currently on cat’s releases *Syncthing version*.*app-counter* (x.y.z.a) is used. I’d propose to slightly extend this to include Syncthing release candidates (x.y.z(-rc.k).a), an example of a version sequence could look like this:
It’s a bit long-ish, but I think it’s the most meaningful option. As there’s currently 0.10.18 betas released, I’d propose to do the transition after that if this scheme meets agreement.
As on option, you could perhaps have a “silent” .0 suffix? That is, the release accompanying v1.1.0 would be just v1.1.0. If you need to re-release with android only fixes, you’d go to v1.1.0.1 etc.
A silent .0 would also work as long as we put …00 behind the android app pkg version number which needs to be increasing every release according to gplay.
The numeric app version (needed for playstore and for adb install -r) is an int32, so maybe just increment it with +1 for every version pushed to Play. In several projects I had this decoupled from the user-visible (string-based) version. Not always good, but also bad if we run out of int32
+1 is easier, but the reports show more meaningful output on Google play if the version code is related to the visible version text.
Currently, I’m using this:
Major x 1000000 + Minor x 10000 + Patch x 100 + WrapperVersion . Downside is it implies there never will be a 100 in between the printed and dotted version.
It could also be bumped automatically by a release script.
As far as I can see in the google play console it displays both the numeric app version and the “normal”/human readable one. So +1 seems fine (and that’s what the release script does too I think).
If using builds from the build server you can also take the build number from there, in $BUILD_NUMBER (may need some cleanup) or %build.number% (as substitution in the build commands).
We just can’t downgrade to anything lower than what is already in Play Store or on user’s devices. Even for developers it would be a pain, since you can’t adb install -r anymore but need to delete the installed version and then install as new application.
Sure. Upwards is the only way. Frankly I think two digits each for major/minor/patch/application is perfectly fine too. It’s unlikely we’ll reach three digit minors or patches in foreseeable future, and when we do there will be plenty of warning. If we completely stopped doing feature changes and just released patch versions from now on we’d get there in roughly 100 months, or 8 years give or take.
Yeah, I’m not really afraid of that, it was just regarding the $BUILD_NUMBER, which will be likely lower than what is deployed at the moment (I assume).
I don’t quite understand why we are discussing this number. It currently is auto-incremented by build scripts and creating the apk amounts to running a release job on build.syncthing.net. What’s the advantage of changing that (unless of course it really needs to be human readable, but I don’t think it does? And even if, then we’d change the build script to generate it from the human readable version as proposed).
@imsodin is right, we can change the number but it’s not priority one at the moment.
Let’s take this as human readable: v1.1.0[.rc1][.wrapper]
Btw: Do we have polls for these
