Implement auto update in Fieldworks Lite #1298
Conversation
![graphite-app[bot]](https://avatars.githubusercontent.com/in/158384?s=60&v=4){kind=small}
…server, if the server returns a release, then the client will update to that version
…controller, markup with otel activities
backend/FwLite/FwLiteDesktop/Platforms/Windows/WindowsShortcutService.cs
Outdated
Show resolved
Hide resolved
|
|
||
| public static bool ShouldUpdateToRelease(string appVersion, string latestVersion) | ||
| { | ||
| return String.Compare(latestVersion, appVersion, StringComparison.Ordinal) > 0; |
There was a problem hiding this comment.
In theory this could simlpy be appVersion != latestVersion.
That would solve are commit-hash problem, but it makes it a lot more sensitive.
In that case, with a bit of parsing we could do a check of this form:
latest.date > app.date || latest.date == app.date && latest.hash != app.hash
There was a problem hiding this comment.
yeah I agree, there's a bunch of different ways we could do it, we could always chose one, but report via otel all the different ways we consider doing it, then we can see over time how they work?
| preferences.Set(LastUpdateCheck, DateTime.UtcNow); | ||
| return true; | ||
| } | ||
| if (timeSinceLastCheck.Hours < 20) return false; |
There was a problem hiding this comment.
I'm fine merging this, but I think it deserves more thought.
Checking for updates is cheap.
Installing updates is not.
So, we're not really protecting from checking for updates, but maybe repeated failed updates?
If we release two updates within 24hrs then we probably have good reason to.
Maybe the logic should be more like:
- Always look for updates on start
- Don't try the same update more than once within 24hrs (unless it clearly failed due to connectivity problems?)
There was a problem hiding this comment.
You're right is is cheap to check. At this point I have no idea what a failed update would look like or how that would even happen considering we're not running any custom code during install. Not that I doubt it could happen. That said, tracking update attempts introduces complexity which I'd rather avoid, so maybe let's leave it as is for now and see what we learn with people actually using it and updating to new versions
Update steps:
https://lexbox.org/api/fwlite-release/latest, can be overridden with an env variableI'm worried about fw lite failing to update itself, if that happens then it makes it hard to recover and the users will need to manually update, I want to avoid that at all costs.
Some failure modes:
We can avoid some of these but not all, I would like to get input from other devs on this.