Minimum supported go version

[ghost]

Hello, first of all:

Thank you so much for your work on this software. I would like to emphasise that I do not deny your efforts and the fact that you write open source software.

However, I have one comment that is a thorn in the side of many users/sysadmins. This is an example for differences between the needs of sysadmins and developers

I wanted to build transfer.sh on a Debian system. I use the current Debian stable, Bullseye.

Problem: ~/.go/pkg/mod/golang.org/x/net@v0.8.0/http2/transport.go:19:2: package io/fs is not in GOROOT (/usr/lib/go-1.15/src/io/fs)

io/fs is only available from Go version 1.16

Debian ships version 1.15 with Bullseye.

So from here on I am dependent on software not provided by Debian stable and one of the most important reasons for using a "stable" distribution is undermined.

To make matters worse, if I want to install a current version of golang, I unfortunately can't find a way to get it from a provided Debian repository on the Go project page.

So I am forced to also take care of the manual maintenance of your software's dependencies. So, besides the updates of transfer.sh, I also have to put the manual maintenance of golang on my list of software to maintain. With transfer.sh, it's only golang. With other software projects, you can put 3, 4, 5 or even more additional dependencies on your list of manual updates.

Further, another problem can arise from this. If the dependency, like golang in your case, is not backwards compatible, it can happen that other programs that are already based on the version 1.15 provided by Debian break.

To be fair: golang 1.19 is available from the official Debian backports repository. I have also used this possibility. But: Only a few days ago you updated your Docker Container to golang version 1.20. So how long will the version from the Debian backports still work? We don't know.

Surely some will now say, use Docker. No. There are reasons for admins not to do this, for example because it simply doesn't fit into the ecosystem you have created on your server. Others simply don't want to deal with the administration of Docker. The reasons are manifold. For me, Docker is just useless overhead. I write a systemd.service file for everything. I start software in screen/tmux if necessary, if it doesn't provide a daemon mode itself. And then I configure nginx to make the service accessible. So resource-saving, so simple, so good (imho). And yes, there are so many ways to fix the problem. But we admins love a cleanly installed stable distribution with as few other dependencies as possible.

So my request to you and an appeal to all the many and important maintainers of opensource software: Please think about writing your software in such a way that the dependencies are compatible with the most important stable branches of the various Linux distributions. (Not only Debian, as in my case).

And again: Thank you for this great software. Thanks also to all the other open source maintainers. You are all doing a great job!

I'm just the admin who installs your software and updates it to make your work available to users. Maybe my text here will make you think of us admins from time to time.

Thank you for your attention.

Martin

[aspacca]

@coacx the discussion about updating the minimum go version required for the software started back in 2022: https://github.com/dutchcoders/transfer.sh/issues/505

this is what I wrote back then:

my goal is to give users the possibility to build from source on any LTS (or equivalent) major system they use, relying on the default repo of the system package manager (or equivalent).
Debian, buster, from backports: 1.15
Anything that can fallback on EPEL, from EPEL7: 1.17

It was noted anyway (back in september 2022) that:

FWIW the official stance from the golang team is to [support two major versions](https://go.dev/doc/devel/release) back from the latest (so 1.17, 1.18, and 1.19 today).

And since:

Debian bullseye is the latest release and its backports support 1.19.

While I was the first one that wanted "that the dependencies are compatible with the most important stable branches of the various Linux distributions", I limited that, in the case of golang, to the official supported versions of the language.

we finally upgraded the minimum golang version only when new changes and features to the project were not compatible anymore with 1.15

btw, you don't need to build from the repo on your debian system: you can just download the binary from the release page. we publish over fifty binaries for different systems and platforms :)

there are a few "imprecision" on the rest of your message that I'd be happy to address if you are interested :)

thanks

[ghost]

Hello @aspacca,

thanks for your detailed answer.

[...] we ended up updating the minimal Golang version only when new changes and features were incompatible with the project [...]

That is a statement that I like very much. But there have been enough situations where such statements have unfortunately vanished into thin air after a while. Don't get me wrong, I will deploy your software because I also trust this statement.

As for your reference to the existing binaries: Sure, that's one of the many possibilities. But that also brings a problem with it. In large environments it is simply not possible to just install/run a binary.

Imagine a large political party, which organisationally functions like a company. There are guidelines that regulate the use of software. One could be "Use Debian stable" - this is considered "safe", and if something happens, the insurance pays (at least in Germany), because you have proven that you comply with a minimum standard.

And another is "If you use other software, it has to pass our security check". These security checks are only possible if you download the source code, check it and build a binary from the checked code.

Build dependencies such as those that force you to use a go-version other than the one provided by the stable distribution are a red rag. Even if it is hard to imagine, the problem is the same as when someone has to install gcc 13 on a Debian bullseye.

there are a few "imprecision" on the rest of your message that I'd be happy to address if you are interested :)

We can also talk in detail. I am grateful for any suggestions. And we can only benefit from each other.

If you want, it doesn't have to be here either, there are other ways to communicate, IRC or something.

[aspacca]

That is a statement that I like very much. But there have been enough situations where such statements have unfortunately vanished into thin air after a while. Don't get me wrong, I will deploy your software because I also trust this statement.

as anything in FOSS you can just hope that mantainers won't change their mind: I made the statement public and you can quote it to me if I'll try to diverge in the future ;)

as for the scenario you described: I know that some organisation can have such constraint, I considered that and that was the main reason I pushed back for a while dropping 1.15 support.

still each scenario is different, and at the contrary there could be ones where updated depdendecies where security fixes are applied, or a supported version of the "stack" are the constraints

there's no solution that will fit every of them.

I honestly thingk that providing compatibility with officially supported golang versions available through backports to stable debian is the best we can do

We can also talk in detail. I am grateful for any suggestions. And we can only benefit from each other.

not a big deal: you can install multiple go versions on your system and use them to build different binaries. in the end the binaries will either be statically or dynamically linked. in the case of transfer.sh I will rather reject a feature than having a binary that's not possible to link statically, so you are quite safe on this day in terms of backwards compatibility

[adamantike]

To be fair: golang 1.19 is available from the official Debian backports repository. I have also used this possibility. But: Only a few days ago you https://github.com/dutchcoders/transfer.sh/pull/550. So how long will the version from the Debian backports still work? We don't know.

As the author of that change, I don't think this is a fair comment. As you mentioned Docker is a no-go in your case, the version upgrade in the Dockerfile shouldn't raise any concerns for you.

Consider that go.mod is still pointing to the oldest supported version, and the CI configuration still runs for 1.18/1.19/1.20. The idea of dropping anything besides 1.20 wasn't even mentioned in that PR.

Maintaining support for older versions doesn't mean everybody must use the lowest common denominator. Docker users can benefit from the newest Go improvements, while the project still supports users that require other installation methods.

[aspacca]

As the author of that change, I don't think this is a fair comment

it was one of the "few imprecision" I mentioned before: you don't need any version of golang installed on the system in order to run the docker image

I don't think @coacx comment meant not to be fair: just it was imprecise :)