"Automatic upgrades" web GUI option in pre-release versions is misleading

[ProactiveServices]

Usually I stick to the release channel and upgrade manually. I wanted to take advantage of a recent bug fix in a pre-release version.

I set the Options to permit release candidates and after upgrading I wanted to set automatic upgrades back to "disabled". The web UI lets me do this, asked for a Syncthing restart, then the automatic upgrades are forced back on, as per pre-release behaviour. I assumed something had caused the config save to fail and tried to diagnose the "problem" :-)

It would be helpful if the Options->Automatic upgrades option showed "Stable and release candidates" and locked the menu to make it clear that the option cannot be changed, perhaps with a tooltip or a brief explanation below.

[calmh]

Changing to "stable releases only" is possible and legitimate so the control itself shouldn't be locked down. But "no upgrades" isn't a valid choice from a pre-release, so that option shouldn't be selectable, indeed.

[danielmreck]

While in the Options screen I accidentally changed the Automatic Upgrades option to allow release candidates. Syncthing almost immediately upgraded and now I cannot switch back to stable releases.

@calmh as of v0.14.34-rc.1 the "Automatic Upgrades" UI element is completely missing from the Options screen, as seen in this screenshot. Where can I change the setting back to only automatically upgrade to stable releases? I cannot find this in config.xml or anywhere else, and I really don't want to go through the pain of completely reinstalling and reconfiguring this machine across the entire mesh.

Allowing users to go down a one-way street into unstable candidate releases is both confusing and frustrating.

Thanks!

[ProactiveServices]

To get back to a stable release:
Stop Syncthing
Edit Syncthing's config.xml , upgradeToPreReleases entry to false
Drop the latest release binary over the top of the existing pre-release
Start Syncthing

[danielmreck]

Thanks, @ProactiveServices. I will do that when I'm back in front of this machine. I recommend that the UI be corrected. (Or, if there's some reason we want to make it extra difficult to go back to stable from release, these instructions should be provided in the release release UI.)

[calmh]

The drop down is absent if upgrades are disabled (by environment var or build option) or if there is an error reaching the upgrade server. Perhaps the latter was the case for some reason when you looked at the settings. It is not intended to be a one way street of any kind.

[danielmreck]

@ProactiveServices I was able to get back to the stable release tree with the instructions above. Thank you!

@calmh Thank you for this additional detail about what causes the upgrade box to disappear. In my case, the only variable that changed was an accidental upgrade to the release track. This shouldn't have changed the environment or build option, right?

Access to the upgrade server should not have been a problem because all the machines on the stable track were still showing the Automatic Upgrades dropdown box -- only the two systems that were on the candidate release track were missing the UI box, which implies a bug unless I'm missing another nuance of intended behavior. These machines were on the same local network, so they all had the same access conditions.

[calmh]

Yeah that seems a bit odd, assuming that the upgrade wasn't delivered by apt-get of course. But I'm also thinking this isn't the best choice in world, how it currently works. It's a bit of a legacy thing - upgrades being disabled manifests as an error when checking for upgrades, and we used this to remove the dialog options that don't make sense when upgrades are disabled. But we should show the options when upgrades are enabled, regardless if there is an error checking for upgrades at the moment.

[danielmreck]

All the machines affected by the accidental move to the candidate release track are 64-bit Windows. There is one 32-bit Windows machine and one BSD machine in the mesh, but they were unaffected.

From a UI perspective, it is better that all options are visible, lest we confuse users when the documentation refers them to invisible elements. Then we can disable specific UI elements with an explanation as appropriate.

(And for goodness of all, let's not bury options under 82 levels of swipe gestures, unlabeled icons, and thin low-contrast/non-accessible links -- looking at you, Google and Microsoft!)

[calmh]

The latter problems mentioned here were #4654 and are now fixed. The original issue remains.