I ‘ve been thinking a lot on auto-updating, but wanted to check with you guys if you see any anti-patterns in my proposal:

Context

I’m coding a game in C++ and SDL, compiled in an Ubuntu (host) for a Windows (target) with mingw32.

Technically, if you copy the needed DLLs + assets into the exe folder, it just works. But I was thinking in Inno-Setup (or any other free tool) to create an installer MSI to ease the life for the majority of users.

Problem

Now my game is in the very pre-alpha-buggy state, but I already have some alpha-testers that help. Currently, I just send them new .exe versions each time and optionally separate files with the assets or dlls, all in a tgz that they decompress in the proper location.

I was thinking in creating an auto-updater system to ease the life for the current users.

What I’ve thought up to the moment

Currently, this is what I’ve thought:

• Setup a remote URI to get the state of versions, say GET http://api.example.com/versions that could respond a JSON with the list of available versions, date of release, and which is the older version you need to upgrade from (maybe to upgrade from 0.0.1 to 0.0.5 you need to download and execute 0.0.4 because it does something in the database with a code that is no longer included in 0.0.5).

• Setup a set of remote URIs to download “something” (that could, for example, be the latest MSI or maybe a TGZ or whatever). For example GET http://api.example.com/download/0.0.4

• When the program starts to run, launch another thread in the background and request the /versions resource to see if there are new versions available. If threads are not available, do it before proceeding.

• If there are not any new versions to download, just do nothing regarding auto-updating and continue execution normally.

• If there is a new version, download the binary from the resource /download/{newest-upgradeable-version-from-the-currently-installed-version} and store it somewhere.

• Flag something at someplace so, the next time the software is launched, it seems there is an update ready to be installed. The old software will then launch the installer and then kill itself, to allow the installer to run without any locked files.

• The installer, upon finishing, would launch the .exe again (which is the new one).

• The new executable will be responsible for any fixtures, data to be added to any database, data mangling, deleting whatever, etc, to achieve a good desired state in the very first run.

• Upon success in the cleanup, the new executable could optionally delete the downloaded binary to avoid consuming silly accumulative space. Then run normally.

Over the paper, seems it makes sense, but maybe if anyone has any experience in creating auto updates can see any antipattern here…

My “light” wonderings

• Any tips in the /versions resource? Anything to take in consideration?
• Binaries: I was thinking initially in a single MSI that can serve both for double-clicking if you download it the first time, or you can silently run it if you pass something like --silent or --quiet… you get me 😉 – This would avoid maintaining two outputs: a MSI for the first-time installer and a TGZ with just files for the auto updater. Is a --quiet single MSI a good idea?
• Where to store the downloaded binary? In a temp folder given by the Operating System? On one side, I tend to think…. “this is why TMP folders are for, no?” On the other side, I tend to think that temp files and folders usually are random names in-process, and maybe it’s better to store that in a well-known location. The first option that comes to mind: “Program Files”, but wait! That’s a “protected” folder. Any “suggested location”?
• What is the best place to “flag” that an auto-updater should be launched? Is there any common practice? First option: Place a lock file somewhere around in the filesystem and monitor if the file exists or not. If locked means “don’t run, update now”. Optionally with version information inside to double check, everything is correct and abort on non-coherent data.

My “hardcore” wonderings

• Any tip for launching an installer from the program to be upgraded? If program P launches installer I and after that P then kills itself, for a few moments P and I will co-exist, so installer I could try to modify locked files (for example P.exe itself). So installer I should “monitor-and-wait” that P is effectively killed (and I should be expecting so), shouldn’t it? any tips on this part?
• I also wonder if it’s better to “keep” the upgrading “functions” in many versions, or just a few: Should version 10 carry “logics” for finding a client of version 3? Or just I should force that every X versions there is a “needed” download? For example assuming 90% of the users will be 1 or 2 or 3 versions behind, maybe if I find someone in v3 and I’m in v10 now, but they did not open the program in a year, they just jump from 3 to 5 then to 8 then to 10. Any suggestions on “keeping upgrade logics” forever in future binaries?

My “most hard question”

• Is this full approach correct? Makes sense? Or I should rethink all from scratch, from another completely different point of view?

THANKS!