Update version of go to >=1.18?

[joshspicer]

For personal use, I currently working on adding support for Azure blob storage as an alternative storage driver (https://github.com/joshspicer/transfer.sh/blob/main/server/storage/azure.go).

I would love to contribute back the Azure storage driver back to this repo. The Azure SDKs require at least go 1.18. I am curious if there's any justification for pinning this project to go 1.15, which is now unsupported.

[paolafrancesca]

@joshspicer we support building from 1.15 till 1.18: https://github.com/dutchcoders/transfer.sh/blob/main/.github/workflows/test.yml#L16-L19

the releases are built with 1.18: https://github.com/dutchcoders/transfer.sh/blob/main/.github/workflows/release.yml#L110ù

we forgot to upgrade the docker build: https://github.com/dutchcoders/transfer.sh/blob/main/Dockerfile#L2

we can remove 1.15 and other unsupported version but not sure about requiring 1.18 as minimum, since it means some users might not be able to build on their own on old system

open to discuss the pros and cons (having azure storage support it's a big pro)

@stefanbenten , what do you think?

[stefanbenten]

Usually its good to require the latest + the previous two minor versions (ie 1.19, 1.18, 1.17) and thus setting the minimum to 1.17 would be a good intermediate step imo.
For Azure i think there is a "deprecated" sdk that can be used that builds with 1.16 and upwards?

[paolafrancesca]

Usually its good to require the latest + the previous two minor versions (ie 1.19, 1.18, 1.17)

in order to clarify: 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).

MacOS: hombrew is almost up to latest release, same macports - no problem here
Windows: I honestly don't have a clue :)
Linux:

• Debian, buster, from backports: 1.15
• Anything that can fallback on EPEL, from EPEL7: 1.17

[paolafrancesca]

to shorten the discussion: @joshspicer you should be able to pin to a non-latest version of the azure sdk and still use azure blob storage

is it ok for you?

[joshspicer]

FWIW the official stance from the golang team is to support two major versions back from the latest (so 1.17, 1.18, and 1.19 today).

I'll see if I can get my changes working with 1.17 so that things are backwards compatible. I would prefer to use the new Azure Blob Storage sdk (https://github.com/Azure/azure-sdk-for-go). Not sure if all the features of this SDK require 1.18, or if I can somehow get away with using the SDK in 1.17

[paolafrancesca]

as far as I know github.com/Azure/azure-sdk-for-go@v59.0.0+incompatible works with 1.17

[paolafrancesca]

@joshspicer is this still an issue for you?

Did you add support for azure blob storage?

[stefanbenten]

@aspacca Debian bullseye is the latest release and its backports support 1.19. I dont think we should support anything older than 1.17 anymore, in the best case i would like even only supporting 1.18+. for the same reasons outlined by Josh above.

[paolafrancesca]

@stefanbenten but debian LTS is buster, unitl Aug 2024 or something like that

[stefanbenten]

Of course, i understand. That said, i do not know many go projects that do act against the recommendation, especially with regards to security patches, etc. Rclone is one of they few that is fairly restrictive and careful about bumping and even they have 1.18 in requirement now..

[paolafrancesca]

@stefanbenten oki, let's support only oldest supported version from go

[paolafrancesca]

resolved with #532

@joshspicer are you still actively relying on your azure storage implementation?

I'd like to add the support, if you want to contribute, or I'd start from your https://github.com/joshspicer/transfer.sh/blob/main/server/storage/azure.go