Update version of go to >=1.18? #98

Closed
opened 2026-01-19 18:28:57 +00:00 by michael · 12 comments
Owner

Originally created by @joshspicer on GitHub.

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.

Originally created by @joshspicer on GitHub. 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.
Author
Owner

@joshspicer commented on GitHub:

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

@joshspicer commented on GitHub: 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). 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
Author
Owner

@paolafrancesca commented on GitHub:

@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?

@paolafrancesca commented on GitHub: @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?
Author
Owner

@stefanbenten commented on GitHub:

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?

@stefanbenten commented on GitHub: 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?
Author
Owner

@paolafrancesca commented on GitHub:

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 commented on GitHub: > 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
Author
Owner

@paolafrancesca commented on GitHub:

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?

@paolafrancesca commented on GitHub: 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?
Author
Owner

@paolafrancesca commented on GitHub:

@joshspicer is this still an issue for you?

Did you add support for azure blob storage?

@paolafrancesca commented on GitHub: @joshspicer is this still an issue for you? Did you add support for azure blob storage?
Author
Owner

@stefanbenten commented on GitHub:

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..

@stefanbenten commented on GitHub: 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..
Author
Owner

@paolafrancesca commented on GitHub:

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

@paolafrancesca commented on GitHub: @stefanbenten but debian LTS is buster, unitl Aug 2024 or something like that
Author
Owner

@paolafrancesca commented on GitHub:

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

@paolafrancesca commented on GitHub: as far as I know github.com/Azure/azure-sdk-for-go@v59.0.0+incompatible works with 1.17
Author
Owner

@stefanbenten commented on GitHub:

@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.

@stefanbenten commented on GitHub: @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.
Author
Owner

@paolafrancesca commented on GitHub:

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

@paolafrancesca commented on GitHub: @stefanbenten oki, let's support only oldest supported version from go
Author
Owner

@paolafrancesca commented on GitHub:

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

@paolafrancesca commented on GitHub: 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
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: dutchcoders/transfer.sh#98