[GH-ISSUE #719] [Discussion/Proposal] Support last 2 major Go releases only #350

Closed
opened 2026-03-02 05:20:38 +03:00 by kerem · 2 comments
Owner

Originally created by @kamikazechaser on GitHub (Aug 7, 2023).
Original GitHub issue: https://github.com/hibiken/asynq/issues/719

This is a proposal to only support the last 2 Go releases in asynq. This also aligns with the Go release policy.

If you use Go < 1.19 this could potentially impact you.

Why?

  • Some PR's (especially the refactor ones) rely on new stdlib features
  • Some dependency upgrades will not pass CI tests on older Go releases, possibly related to above

Changes

  • Update CI to run tests on 1.19+ or later
  • Update go.mod directive to 1.19 or later

Refs

Originally created by @kamikazechaser on GitHub (Aug 7, 2023). Original GitHub issue: https://github.com/hibiken/asynq/issues/719 This is a proposal to only support the last 2 Go releases in asynq. This also aligns with the Go release policy. If you use Go < 1.19 this could potentially impact you. ## Why? - Some PR's (especially the refactor ones) rely on new stdlib features - Some dependency upgrades will not pass CI tests on older Go releases, possibly related to above ## Changes - Update CI to run tests on 1.19+ or later - Update go.mod directive to 1.19 or later ## Refs - https://go.dev/ref/mod#go-mod-file-go
kerem 2026-03-02 05:20:38 +03:00
Author
Owner

@hibiken commented on GitHub (Aug 13, 2023):

Thanks for opening this issue with a proposal.
I'm for it -- if others don't have major concerns, we can go ahead and update the README and drop support for older go versions (also make sure to update CI build to drop those go versions)

<!-- gh-comment-id:1676182919 --> @hibiken commented on GitHub (Aug 13, 2023): Thanks for opening this issue with a proposal. I'm for it -- if others don't have major concerns, we can go ahead and update the README and drop support for older go versions (also make sure to update CI build to drop those go versions)
Author
Owner

@ghstahl commented on GitHub (Aug 13, 2023):

I am in a situation where there are no such thing as legacy compilers. Every docker image that we release gets scanned and we fail soc 2 compliance because of golang. Which is actually good, it forces use to NEVER get behind. The week a new golang comes out we upgrade across the board.

So, my vote is: Never support legacy EVER. Old stuff had vulnerabilities.

So, in the words of an American Treasure, Taylor Swift.
We will Never, Ever support legacy compilers.

<!-- gh-comment-id:1676465927 --> @ghstahl commented on GitHub (Aug 13, 2023): I am in a situation where there are no such thing as legacy compilers. Every docker image that we release gets scanned and we fail soc 2 compliance because of golang. Which is actually good, it forces use to NEVER get behind. The week a new golang comes out we upgrade across the board. So, my vote is: Never support legacy EVER. Old stuff had vulnerabilities. So, in the words of an American Treasure, Taylor Swift. We will Never, Ever support legacy compilers.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/asynq#350
No description provided.