I’m not seeing specific mention of “sets a schedule” on the Duplicati.Library.AutoUpdater page. I’m seeing “install updates” and “Install the latest update from the currently selected update channel” which stops the wish to install a specific version. That’s not what Duplicati considers an autoupdate. Duplicati is not yet as sophisticated as Windows in its update configurability (some would say Windows still has a way to go…), however it does allow different channels. The main ones in use are beta and a take-your-chances canary.
Another reason why upgrades tend to go up is because database formats go that way, and while “up” will always be planned for, “down” is not. Maybe what you really want is a do-it-yourself version of “up” though, and this can maybe be approximated by not running the autoupdater until you’re sure you want the update.
Sometimes admins prefer to have very specific control, so there may be a case for a feature to have that. Such a feature might tie in with some of the occasional discussion on automated large-scale deployment. Duplicati is not a large binary, so making the usual install work well in an automated rollout might save the added work (only so much work can be done…) of coming up with a good way to do updates-not-installs.
Also see comments elsewhere on channels, and upgrades versus downgrades. Beta versions appear to show up almost a year apart, so what sort of specific versions do you have in mind within the limitations?
Duplicati on Windows - two version numbers has much technical information on the update mechanism, including why Duplicati possibly chose to do what it thought was better than the typical upgrade-by-admin.
I’m kind of curious if the CLI updater knows how to restart the server (or Windows service), however CLI generally is quite independent, so you might need to use some OS mechanism to achieve such restarts, and restart should take care of the web interface showing the old (but still running) version before update.
I can’t provide a guaranteed good explanation of the documentation (maybe this is your “schedule” point?) however I think policy is most applicable to CLI use, and you have a choice of when you check for update, and when you download and install that update, all relative to the CLI command work that you are running. The code default appears to be CheckDuring, which sort of fits with the experience I’ve had, which is that check is automatic, and install is not. The ability to change update policy is presumably to give the choice.