Updater for Windows installs

[simonsan]

As we come near that point where we will have automated CI-builds with Kevin, we should start to think about how we keep people informed that there is a new version of openage.

While there are many really complicated solutions out there, I would prefer an easy solution. Right now the installation works mostly out-of-the-box and is somehow portable. It would be nice, to keep it that way and stay away from deeper system integration. My 2 cents.

For this I would prefer to use the GitHub API to check for new release. We could add a version tag to the openage.bat and an update check before the game starts. While I was already implementing something like this for GitHub releases in the dependency setup script for Kevin, something like this would be ready to go. We would call powershell-script, we deliver inside our installer, that takes care of checking for release updates, informing the user that there is a new version and asking to update. Then replacing the old installation completely using a quiet-call of the newly downloaded installer (we have to see how that works out with the "untrusted installer warning though). Afterwards it could turn off update check for the next run of openage.bat and start. While we could also think about to patch the directory, I feel the approach of replacing the installdir completely might fit openage better, as we maybe don't want to check all the time from which version people are upgrading. Also the installer is kind of small with approx. 30 MiB. And we will throw out new installer builds just now and then. If we see, that it gets too much, we could still reconsider changing our upgrade procedure.

What do you people think about this?

In Addition, small draft:

• [ ] Compare installed openage version with new release
• [ ] if newer release available, download newer installer build
• [ ] check for hash of downloaded file
• [ ] make backup of old installdir, compress and store in appdata-backups folder (one or two versions from the past, auto-delete older versions)
  • [ ] for future config changes, we might want to consider storing them in appdata
  • [ ] possible problems: future changes to the converter would probably break old conversions, we should think about if we could check for old existing conversions and convert them to newer asset versions automatically at the first start of openage

For the Installer:

• [ ] uninstall old openage
• [ ] install new openage version to same directory like before (saved in temporary env or file)
• [ ] set openage_updated => true to show changes to release at first start (if we don't already show release notes in one of the installer pages)
• [ ] execute openage.bat skipping update-check at first start

For the portable archive:

• [ ] tbc

EDIT: This should be just a temporary solution until the launcher takes over.

[TheJJ]

As long as there's no proper package manager for Windows, each program needs to ship its own package manager, i.e. updater.

For us, this should be the game launcher. Checking some api (be it at openage.sft.mx or github.com) is seems the right way.

I don't think it should be a priority to deliver updates to windows right now, we have other much more important areas of construction going on, just my 2ct :) If somebody goes ahead though, I won't stop them.

I imagine that a good way for updating under windows is to have an unique, version based folder name for all the binary and python stuff. The launcher can then just fetch a new version to the folder, so both could even coexist. Old installations can be purged by the launcher. Which version is launched, can also be selected in the launcher.

Even though we don't have a launcher, we should design the update process in a way that we just don't have a launcher gui for now, but the mechanism should be the same already to simplify and prepare the creation of the launcher in the long run.

[simonsan]

@TheJJ There is a package manager, I use chocolatey on my productive system to hold my packages up-to-date and in the setup script to install three quarters of the dependencies. I mean I already wanted to try to package one time, if you want I can take a look there and we think about a choco-package.

https://chocolatey.org/docs/getting-started#what-are-chocolatey-packages

I don't think it should be a priority to deliver updates to windows right now, we have other much more important areas of construction going on

Same, it is a "nice to have feature" at this stage, sure, but with some great changes coming up in the nearer future (e.g. modding) we also want to make sure that people stay on the latest release to get the best experience and also get in touch with the overall changes.

I really like the idea of version based folders and the launcher choosing the version to start. Let me make a small research on this chocolatey packages: what we need to do for that, if it is free for open-source organisations, etc. and get back to that topic later. Thanks for your feedback!

[Jogai]

The question is; Does the target audience have choco? Not a lot would be my quess. I used it, but it felt too clunky back then. Now I mostly use portable packages (not specific to a solution like portableapps.com, mostly just zip distributions, but some more specific like chrlauncher for chrome).

I tought scoop was better but its target is even more limited. There are other autoupdaters, but I dont think you can expect users to have them.

Publishing on choco will have the advantage of discoverability, so it would still be a good idea.

[simonsan]

@Jogai After some research for chocolatey I see this, too. As we are shipping external libs and stuff i'm not sure we could host that on the official channels of chocolatey, which would bring us to hosting it in other community repositories or ourselves (with this the discoverability advantage is gone). As you said, many people might not even use it right now, although we could be one of the early adopters then, I would not take the chocolatey approach anymore. I started to create the package already, but the way it is packaged is basically just another layer of install scripts. I'm not sure, if this is really what we want. Also it will not really take away the burden of updating and archiving openage-versions completely. Basically it's just a wrapper for installing and uninstalling software, although there is a modifier that will be executed before any of the both actions, i don't think this is a nice idea anymore. Or do you have any thoughts about this?

But I was reading a bit about different launcher ideas in #920 and at vcmi. I thought about this:

Maybe this is finally a reason to start implementing the first state of a game launcher like @TheJJ said and directly bring the project forward, instead of opening another constructions side. First we could just implement the basic configuration (everything openage.bat does) and an in-place updater that moves the old install files into a version-based archive and downloads a new, updated archive from our release page and extracts it.

We would need to add another target for cpack like ZIP for this. We could also get around that annoying "unsigned software"-warning of Windows with this. I'm not really sure, what the NSIS uninstaller says after replacing the files in the directory. Right now it just removes files that it installed itself. In the moment you change something it will let this file in the installDir when uninstalling, so I'm not really sure, how we would do it with the archive of versions then without breaking the uninstaller. Any ideas?

[simonsan]

Also there are already some launcher ideas that you can find in #751 or directly here.

[simonsan]

Addition: The packaging pipeline gives us also portable builds of openage with the full version string in the filename. This we could make use of in the updater with either using these archives for in-place replacement of the old version (without the annoying windows warning for installing non-signed software) or even to do some versioning and let them run next to each other. The launcher (#920) could organise this structure and launch different versions to the users liking.