The version number does not change

[mic140]

After updating to version 57.1, the version number in the program itself remained 57.0

[ratti]

For those looking for a reason why their "Obtainium" app-updater fails to update: This is the reason. It tries to replace 57.0 by the new 57.1, just to find 57.0 again.

[mic140]

I took the file from here

[ratti]

That's what Optainium is doing also. It updates apps directly from here.

[mic140]

The file that is posted here as version 57.1 in its properties has version 57.0. And it is installed exactly as version 57.0, even if you do not use Obtainium.

[ratti]

@mic140 , my impression here is we talk in a circle, and I guess that's caused by me, because I typed my first comment on a smartphone and was not verbose enough. Sorry for that.

So... being more verbose:

The bug is: The package that can be downloaded in the release section is the 57.1 , however, if you install it it is identifying as 57.0 in different places. That is the bug, not more, not less. I am not doubting that, and it's not related or caused by other tools.

Seeing it in that way this is a minor issue, and since it won't be hotfixed it's even a "wontfix" (since fixing the release number requires... a new release number) So... sad, but harmless.

What I wanted to add here is a different view on that issue: There are "automated installers" out there, and they rely on the version number: Package managers, alternativ app stores, Obtainium, etc. For example, I don't know how F-Droid will react on a 57.0 that is in real a 57.1

Seeing this issue from their perspective, this is not a minor bug anymore, it's potential harmful. That "updater" sees a new version, downloads the apk, installs it, but then it sees an update available again. Endless loop consuming ressources.

Imagine (I don't recommend that!) someone has configured his software updater tool to auto-update packages and allow mobile data usage. Boom, monthly data amount consumed, maybe Github account blocked for "abuse" by permanently accessing the same file.

So... I don't want to blame someone, nor demand something. What I kindly suggest is:

• Increase severity, since it may harm other software.
• Make sure it won't happen again, by automatizing the version number handling.

Maybe, just to add some perspective here: I don't want to blame others for me being an idiot ;-) , however, that happened to me: I was trying to manually update for like an hour , because I believed "the package installation was failing silently, I have to find out the reason and fiddle with permissions and do something, so it installs" until I understood it did install.

[mnalis]

Increase severity, since it may harm other software.

Well, I wish if github did have severity field! Alas, it does not seem to? One can try to simulate those with labels; but I guess the issue is clear here: it is a known problem, and will be solved as soon as another release is ready, which hopefully should be soon.

Trying to rush out half-working code just to fix version mismatch would not be ideal (for hopefully obvious reasons).

Although one could try to antedate some version bump (e.g. v57.2 / 5703) which would basically be the same as the current software version (to avoid problematic code flux) is possible, but as it requires extra fudging probably not worth it -- unless the new release gets delayed by months, in which case it should be considered.

So, the issue, as you note, will solve itself automagically when new release is made, hopefully soon. I wish it won't trouble too many users until then, like it did you - sorry about that. Devs are busy working out the kinks on new one. I 'd rather not derail them out of the zone, as I see them hammering out commits constantly.

---

What might be useful though, is to have scripted procedure for making a new release (even just a manual checklist if automating the whole things is too problematic) and stick to it, which would avoid this kind of problem in the future.

[ratti]

Thanks a lot for that detailed information, then "it is what it is". I suggest to leave the ticket open until next release, even it's technically a "wontfix", to keep it visible on github issues list.

Thanks for your excellent work, and "happy mapping"!

[mnalis]

@mic140 , @ratti Does it work for you now in https://github.com/Helium314/SCEE/releases/tag/v57.2 ?

[ratti]

@mnalis Thanks, 57.2 works fine in Obtainium.