Faster migration to newer Go releases

Development
1

I want to start adopting new Go releases faster than we’ve done historically. I propose that our policy is that Syncthing should build with the previous stable Go release. That means Go 1.6 currently, as Go 1.7 is the latest. It becomes Go 1.7 when Go 1.8 is released and so on.

Specifically, I’m looking forward to actually using the Context support in Go 1.7, and subtests/sub-benchmarks.

I’m even more looking forward to some things in Go 1.8, which we will be able to take advantage of in about seven months with this policy:

  • More Context support
  • sort.Slice is nice
  • Automatic \\?\ support on Windows, including globbing and so on, which lets us remove a fair chunk of code.
  • os.Executable which lets us remove a dependency
  • Support for ChaCha20-Poly1305 on TLS (which I hope we can use anyway as soon as it’s released)

I’m sure this will be painful for some people, but it still gives everyone at least six months notice before they need to take five minutes to upgrade their compiler.

3 Likes
2

Or, they can in all cases just use the static binaries from github.

3

Yes, of course. I’m talking strictly about developers and distribution packagers here. Everyone else should get a nice freshly baked binary compiled using the best available compiler. :slight_smile:

2 Likes
4

We’re beta software, so far atleast, I vote we live on the edge and only commit to supporting the latest stable.

3 Likes
5

So it shall be. We wouldn’t necessarily immediately jump to depending on 1.8 on release day, but the official stance is that it’s guaranteed to build with the latest stable compiler and this is what we recommend you use.

4 Likes