I’m thinking v2.0.4.13-2.0.4.13_canary_2019-01-29 through (so far) v2.0.4.22-2.0.4.22_canary_2019-06-30 however if you’re not testing bleeding-edge canary releases, v2.0.4.21-2.0.4.21_experimental_2019-06-28 might be what you had. Typically experimental is pretty stable and leads to beta. This time though, that has not yet happened, and v2.0.4.23-2.0.4.23_beta_2019-07-14 is the previous beta plus a necessary warning. Rushing out a truly updated beta was considered too risky due to the extent of change, however so far the field experience of some (unfortunately not known) number of experimental users seems to be quite good.
Depends on what “got running again” means. If you revert to experimental, or canary if you had that before, then conversion to truly newer database versions is automatic. Downgrades would confuse the old code…
Given the wide variety of installers in existence (consider Linux, for example), I’m not sure whether it would be possible for the new code to warn the user (and if it warns, a “cancel” option would be nice to go with it). You could open a Feature category topic to see if people will discuss it (it might not actually get done soon).
If you mean the installation done entirely by Duplicati to upgrade itself, that’s maybe more workable, and will also avoid accidental downgrade because it’s channel-aware (within channel, things should move forward).
Those who install manually can have issues, and the release note could have had a better warning without assuming people understand the risk of changing channels. Relative to prior beta, it’s exactly correct, but if one is on something else (e.g. a recent canary), it’s downgrade of most everything since the previous beta.
I’m assuming your update was a manual update, or your experience disproves my “stay-in-channel-is-OK”. Using the Duplicati updater, one can find the prior version easily (and read changelog.txt), but not if you run update as an install, which updates the base version. If you have old backup emails, they show the version.