Have you read this? #56

To comment specifically on this: no matter how you put it, there's always going to be some scenarios that's not perfectly aligned with the workflow proposed here.

The current implementation is very lightweight. The backend works by downloading the first few bytes of the update file, which contain the hash of the version, and that's compared against the currently installed version. If the two match, then the installed version is the same as the one offered by the server, if not, the application suggests an update. It's minimal processing, minimum number of data transferred, very efficient in my opinion.

It does not have any way to tell which version the update is. For that, the entire update would have to be downloaded or to provide an additional file which specifies the version or to check the redirect URL. That's extra infrastructure. But that's not the main issue. The main thing is, with just that, it still wouldn't cut it, because multiple updates may share the same "version". Version is kind of meaningless here, it's just for users to kind of tell where they are situated. This really is based on commits - the updates are just compilations of a specific commit. Some commits do not increment the version number (located in version.h) at all, so they are technically the same "version".

The update system offers two simple tiers:

• Pre-releases - all commits get compiled automatically on GitHub Actions and a pre-release package is published. This way, users have access to the latest staging code without needing to setup their own build infrastructure. These may contain rough edges, unfinished functionality, crash due to less tested new developments, but are a way for people to test the new stuff and report back on them.
• Releases - specific pre-releases that I manually determine based on the observations around here that are kind of stable or relatively bug-free are promoted as releases and these get pushed to most users.

So yeah, using versions is not enough because especially pre-releases often are names with the same "version". With releases, this shouldn't happen, because those are hand picked manually from time to time. The functionality is basic now, you're on a version you got from pre-release, you switched to releases, of course it wants to switch you back to the release as it sees that is different.

Really, without additional complicated checks that just complicate the system too much for a very specific use case, there isn't an easy way to determine where on the timeline a specific installed version is. And like, it gets convoluted: in your scenario, the app should know you're on an official commit (you can also compile your own version which comes with making an "unofficial" commit then, and there's no way to tell that), check in the list of updates to see where that is located, and determine whether the proposed version is newer than this one and if it's in the channel (pre-release/release) that you have selected. Yeah... is this really required...? I mean, yeah, all this is doable, indeed, but the kind of thing that's called a small matter of programming. I don't feel like it's worth investing all the energy into that.

As a mitigation that may be more easily done in the future is to show which "version" a certain update is designated. That can kind of be extracted from the URL. That's more doable. It's actually something much easier to pick up by someone interested in working in this area. That would mitigate the situation you're describing, I think.

Or, just disable updates until you get back to a release. I understand, you switched to the latest pre-release because you did not really care in testing staging versions, probably wanted feature 'x' from there and don't want to get newer "beta" versions which may break some things. That's fine, I understand, but I can't promote pre-releases to releases either without taking some time to evaluate them, because things break and that's not good for most people. And like, it's a GitHub project maintained by mostly one guy, you are highly encouraged to get involved and help contribute make it better, I don't have all the time in the world to work on polishing every area of this.

And, please, do not disregard pinned stuff. It takes less than 5 minutes to read.

Thank you

@yetisyny I have implemented functionality that treats this use case and does not suggest the older stable version as an update when the user is using a pre-release version but has switched back to the stable update channel in the latest pre-release (22000.434.41.12). Indeed, it's better this way. Additionally, a new feature is also that the notification that gets displayed when an update is available now includes the version number of the update.

Thanks for the report.