There's a lot of anguish in #9282 and the corresponding forum thread about how we should not allow auto upgrades to versions that don't work -- which, on the face of it, is an entirely reasonable request. What I don't see is anyone volunteering to test every release on a giant lab of systems running unsupported OS versions, so if we're to do anything we need to be a bit more proactive. I suggest the following:

• Our major driver of unsupportedness is the Go compiler and runtime.
• If a platform is supported by Go, and Syncthing runs on it, we consider it "supported" at that point.
• When a platform is no longer supported by Go we consider it "unsupported".
• Once a platform is unsupported, auto upgrades are disabled on that platform.

The last point is something we'll need to implement on our side. Essentially, we'll need to add code to detect the OS version, and when a new Go release comes out we do a last release with the previous version plus code that disables auto upgrades on the unsupported platform.

Users with a normal auto upgrade cadence will thus reach this last milestone version and then be stuck there. We should add a startup notice that informs about this fact as well, which could go away when auto upgrades are manually disabled.

Users turning on an unsupported system that's been dormant for a long time might "miss" this release and their Syncthing won't know better than to upgrade to the latest release. If a long time has passed this may fail, like the situation is today. More usually there will be a period of months to years between a platform being "unsupported" and actually ceasing to work, so they'll get one upgrade to a slightly too-new version and get stuck there instead.

Potentially, we could allow an opt out --allow-unsupported-upgrade or something for the more intrepid retrocomputing enthusiasts.

Alternatively, we could send an OS version header to the upgrade server and let it make the decision. It could then return the latest version supporting that operating system. This would handle systems sleeping over the transition, at the price of sending more data to the upgrade server, and making the server more complicated.

This all seems most relevant for Windows and macOS, which have defined versions with defined end-of-life schedules. There are supportedness issues on the BSDs etc as well, plus with old Linux kernels, but the users will generally know to manage this better than us, I expect.

Discuss.