I have been doing some digging, by impression is that it's harder that it seems, but not for technical reasons,this is more of a "what features we want to provide".
Disclaimer: all I say here is for Windows, some things could be reused, but not much.
First, if you only want to use stable and some automatic self-update, that is, have the same experience as let's say a Ubuntu user. Chocolately get the job done (provided you can install in "Program Files" as Chris points out).
It makes the upgrade process really simple, but honestly, unless the self-update is provided by the launcher there's not much value for a normal user. Chocolately is not integrated in the launcher and requires you to run commands manually.
So, going back to how to integrate stable versions update in the launcher, I was thinking...
1. Invoke `GET
https://api.github.com/repos/OpenMW/ope ... ses/latest` to get the last release and version number from the tag
2. Compare version to some config file or use the Windows registry keys. I've seen that CHANGELOG.txt begins with the file version but seems too dirty.
3. if (there's a newer versions)
get the download url for the correct "asset" attribute and run the silent installer (/S for windows)
display that there's a new version and enable an option to update
else
display that this is the "current" version
Outside file permissions, the only problem here is that GitHub's API anonymous usage has a limit of 60 calls, per hour, per IP. Don't think it should be a problem unless there are a bunch of users behind some proxy...but still I think it should be considered.
Now, dealing with file permissions. This is my thinking, taking into consideration I don't have much experience in this things.
The "update" option should copy a separate "updater.exe" to a temp dir, launch it passing as argument the download url and close the launcher.
Ideally, the "updater" should guide the user with some wizard with options like:
· New installation: in case the user wants to keep old version. In this case, just download the installer, run it as-is and close the updater. If the user chooses to install in the same directory as the current installation, it's HIS/HER problem!
· Replace: this the tricky part. To be 100% nice we should check if the user has more than one installation (can be done via windows registry) and if more than 1 is found, ask a nice "Are you sure you want to delete all?". If the user confirms or only 1 installation is found, just run the installer and then the uninstaller silently (/S).
I bet Thunderforge would explain this much better with some cool mock-ups
Now, for nightly builds, the url provided by ACE is always the same and I haven't seen any way to check the version. So, dead end here.
Maybe add a generated JSON with the version and tag number to replace the usage of GitHub API by a similar GET call?
However, important thing here. Nightly installer does not include the commit tag in the installation directory, so in this case there's no failsafe process. When selecting "Replace", it should run the uninstaller first.
In all scenarios, afaik, config files are not tocuhed.