becm That delay is worth designing around rather than waiting out, because the metadata file and the artifacts it names are separate objects and there is no moment at which they are guaranteed to agree. Whichever is updated first, an updater that treats the text file as the version oracle gets a window where it either requests a file that isn't published yet, or is told the old version while the new one is already sitting there.
A few rules make that window harmless. Take the version from the artifact rather than the pointer: on Windows the MSI carries ProductVersion and the installed version is in the uninstall registry key, so the comparison happens between two authoritative values instead of between a scraped string and a registry entry. Compare version numbers component by component and act only when the candidate is strictly newer, so a stale pointer produces "nothing to do" rather than a downgrade, which is the outcome that actually breaks machines. Treat a 404 on the file you were told about as "retry later" rather than an error; on its own that removes most of what you saw. Verify the checksum or signature published alongside the file before installing, and read a mismatch as "the release is still in flight" rather than corruption, since that check is what confirms pointer, file and digest belong to the same release. And revalidate the metadata request instead of accepting whatever is cached, logging what came back, so that when a run behaves strangely you can tell immediately whether you read a stale copy in transit or a genuinely stale file at the origin.
A floor helps as well: don't act on a release until it has been visible for some interval you pick. It costs nothing on a client updater and it turns a race you have to reason about into one you simply don't enter.
