Plans for older Windows releases

bt90 · February 1, 2023, 9:24pm

Go 1.20 just dropped and it comes with a deprecation warning for older Windows releases:

Go 1.20 is the last release that will run on any release of Windows 7, 8, Server 2008 and Server 2012. Go 1.21 will require at least Windows 10 or Server 2016.

Will the Syncthing project stick with its default update cadence for the Go toolchain and discontinue support as soon as it comes to that, or will there be some sort of best-effort release for these OS versions?

To be perfectly honest, I’m not concerned either way, but I’m afraid it’s going to be a hot topic when we pull the plug.

calmh · February 1, 2023, 9:37pm

We build with the latest Go. (Though we maintain compatibility so that you can build with at least the previous version.)

Historically there’s been a difference between what Go officially supports (for running the compiler) and what the resulting Syncthing actually runs on. For example I remember syncthing actually running on XP long past its official expiry date. It might simply be the case that they’re going to remove builders for unsupported Windows versions so there will be no future testing, and newer APIs will slip in over time, in which case it’s entirely possible that Syncthing built with Go 1.21 will run just fine on Windows 7.

Generally, for any deprecation, my personal policy is that if you need to run an old OS you will have to live with also running older versions of some apps, like synching. In this case, any Windows released in the last almost decade will still be fine, so it sounds fairly reasonable.

For the moment you can’t even build synching with Go 1.20 because the quic package hasn’t been updated for it yet. Someone will file a bug on that in 3 … 2 … 1 …

tomasz86 · February 2, 2023, 5:42am

One potential problem that is likely to happen sometime is that Syncthing will auto-upgrade and then refuse to launch again, possibly breaking the synchronisation for a while on some systems (until the user becomes aware of the problem). Ideally, it would be great if auto-upgrade was able to disable itself if the new version is known not to work in the particular OS…

calmh · February 2, 2023, 5:57am

That’d be cool but I don’t think it’s feasible. Apart from anything else I’m not sure how we’d determine “known not to work” ahead of time other than maintaining a giant lab of every operating system and testing new releases on it, which I don’t think you’re volunteering for.

Also “work” is a bit diffuse; if syncthing doesn’t start that’s an obvious fail, but I don’t think thats what’s going to happen when the incompatibility finally hits. It’s more likely to be like a too old arm-Linux kernel with the “accept4(): not implemented” type of problem.

Easier is to only provide upgrades to Certified Supported™ operating systems but I don’t think we want to do that.

What we potentially could do is check the new version doesn’t crash on startup after upgrade, or we undo the upgrade. Whether that’s valuable or not I don’t know.

bt90 · February 2, 2023, 7:17am

calmh · February 4, 2023, 8:29am

For what it’s worth, this clarification was posted earlier by one member of the Go team, in relation to dropping support for older macOS releases but I think the same applies to Windows.

What dropping support means is that we no longer fix bugs that only occur on unsupported releases, and we no longer run our tests on old releases. That includes both running the Go tools, and running programs produced by the Go tools.

We don’t go out of our way to cause Go to break on unsupported releases. That said, there are occasionally cases where we change Go to require APIs that are only available on newer releases. That has happened on macOS in the sense that we no longer support 386 or arm at all; we only support amd64 and arm64. I don’t know offhand if there have been other such cases for macOS (there have been for Linux: for example, we now require the accept4 system call to be supported (except on arm)).

Our position is that it is actually Apple that is driving the upgrade cycle you mention, not us. Apple chose to drop support for High Sierra back in 2020, so anybody running a High Sierra system connected to the Internet is at risk. Should we invest our limited resources on supporting releases that even Apple has declined to support? If Apple continued to support High Sierra, so would we.

(https://groups.google.com/g/golang-nuts/c/Hp_OuiOaisk/m/b6cOj5RCAAAJ)

bt90 · February 4, 2023, 8:45am

And the discussion regarding the Windows change:

Going a bit offtopic but go 1.20 seems to come with a few path handling surprises:

github.com/golang/go

path/filepath: mishandling of Windows UNC paths

opened 10:10PM - 19 Oct 22 UTC

neild

NeedsFix

UNC paths with a `.` host are not recognized as UNC paths: ``` filepath.Clea…n(`\\.\C:\a`) // \C:\a filepath.Clean(`\\.\NUL`) // \NUL filepath.Join(`\\.\C:`, `a`) // \C:\a ``` This causes `Abs` to produce incorrect results when cleaning the path of reserved device names: ``` filepath.Abs(`NUL`) // \\NUL ``` `Clean` converts a path starting with `\\` to one starting with only one `\` if the path doesn't contain non-zero host and share components, and `Join` will drop the leading `\\` from the first joined element: ``` filepath.Clean(`\\a\`) // \a filepath.Join(`\\a`, `b`) // \a\b filepath.Join(`\\a\`, `b`) // \a\b ``` `VolumeName` does not normalize separator characters; this is inconsistent with most other `filepath` functions which `Clean` their results: ``` filepath.VolumeName("//a/b/c") // //a/b ``` ---- The proper handling of incomplete UNC paths is somewhat ambiguous, since `\\a` (for example) is not a valid Windows filename. Ideally, we'd return an error for invalid paths, but most of these functions do not return errors. I think the simplest behavior is to always preserve a leading `\\` when present, so ``` // Correct (IMO) behavior filepath.Clean(`\\a`) // \\a filepath.Join(`\\`, host, share) // \\host\share ``` @qmuntal

calmh · February 4, 2023, 10:55am

It’s not clear to me if that change matters to us or, if it does, whether it’s good or bad. Gut feeling says “should not matter”, unless maybe someone entered a funky UNC path manually, but someone on windows could test or just think about it.