Upgrade 2.0.7.1_beta_2023-05-25 to 2.1.0.2

How-To
10

My point (which may or may not be right) was that if the manifest at, say,

https://updates.duplicati.com/beta/latest.manifest

is the 2.0.8.1 one, then the checks would pass for a pre-2.0.8.1 Duplicati.
That would do as desired, taking the user to 2.0.8.1. Presumably 2.0.8.1
manifest provides 2.0.8.1 with its new
"UpdateFromV1Url":"https://duplicati.com/download for next jump.
Jump destination is unknown at 2.0.8.1 time, and is also a moving target.
Having once done a manual jump into the 2.1 versions, next will use the

https://updates.duplicati.com/beta/latest-v2.manifest

which is kept current. Question is do you have the old non-v2 manifests?
What I mean by that is probably those for the last non-v2 Duplicati made.
Per my summary above, Experimental may be 2.0.8.0, Canary 2.0.7.103.

My point was that these are two different URLs, so the manifest can differ.

EDIT 1:

Put the line above on hold. I’m thinking the problem is that 2.0.7.1 seeing 2.0.8.1 (when that shipped) was fine, but trigger for 2.0.8.1_beta_2024-05-07 to show a “Manual update required” dialog was 2.1.0.2_beta_2024-11-29 manifest’s arrival, which is also (as they share a URL) when pre-2.0.8.1 broke from the check code.

I thought I saw a post recently (maybe based on usage reporter stats) of how many users were on older versions. I don’t know how fixable this issue is, but leading a significant percentage of users through struggle, support need, or leaving is bad…

EDIT 2:

If the .NET Framework build, test, and release infrastructure still runs (e.g. to allow hotfix to 2.0), then if latest.manifest can use it (say it’s called 2.0.8.2), then 2.0.7.1 can update to it per original design idea, then 2.0.8.2 can have a fixed update plan, such as a different manifest URL, or even (very crude) coded to know it’s obsolete.

EDIT 3:

The (let’s call it latest-v1.5.manifest) could probably be what latest.manifest now is, pointing to 2.1.0.2, but not breaking from that, just as 2.0.8.1 doesn’t break.

EDIT 4:

If there are already some semi-hot fixes you’d want to put on 2.0, there’s a chance for 2.0.8.2 to not be purely an updater retry, but I’d sure hate to add any regression.