antlr4
antlr4 copied to clipboard
antlr
Go runtime should not depend on Go 1.22 yet
@jimidle bumped the Go version to 1.22 in https://github.com/antlr4-go/antlr/commit/4d7e18847d8881a176db3d7cca909e3f3942a05f (released as v4.13.1), but the Go version in this repo is still set to 1.20: https://github.com/antlr/antlr4/blob/master/runtime/Go/antlr/v4/go.mod#L3
My request is to downgrade the Go version in the https://github.com/antlr4-go/antlr repo, because it promises to be a clone of the Go runtime in this repository.
Another reason is that the version bump would force projects using the ANTLR Go runtime as dependency are forced to use at least Go 1.22, while Go 1.21 is still officially supported.
The source in that other tree is not yet updated. The “fix” is the other way around.
On Fri, Jul 26, 2024 at 02:34 Maarten Sijm @.***> wrote:
@jimidle https://github.com/jimidle bumped the Go version to 1.22 in @.*** https://github.com/antlr4-go/antlr/commit/4d7e18847d8881a176db3d7cca909e3f3942a05f (released as v4.13.1), but the Go version in this repo is still set to 1.20: https://github.com/antlr/antlr4/blob/master/runtime/Go/antlr/v4/go.mod#L3
My request is to downgrade the Go version in the https://github.com/antlr4-go/antlr repo, because it promises to be a clone of the Go runtime in this repository.
Another reason is that the version bump would force projects using the ANTLR Go runtime as dependency are forced to use at least Go 1.22, while Go 1.21 is still officially supported.
— Reply to this email directly, view it on GitHub https://github.com/antlr/antlr4/issues/4663, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ7TMCQ4HPTPR36MUUFJILZOICZJAVCNFSM6AAAAABLQCJ7DCVHI2DSMVQWIX3LMV43ASLTON2WKOZSGQZTCNZRG43TONA . You are receiving this because you were mentioned.Message ID: @.***>
Thanks for the clarification! In that case, I would like to repeat my request to not yet depend on Go 1.22, since Go 1.21 is still supported :slightly_smiling_face:
as a apolicy, I keep the runtime at the latest version of Go whenever we make a new release. I won't go backwards though. Given Go's backward compatibility guarantee, it should not be an issue for anyone to upgrade, though I know corporate devops can be slow to do such things. Think of it this way: We know that Go 1.22.x has security fixes over Go 1.21 - so we should upgrade.
What is your particular problem with upgrading?
The problem is that, with this policy, this library forces other modules that depend on it to upgrade their Go version, even when this is not strictly required. Our module structure is quite complex: while we like to keep our dependencies up-to-date as much as possible using go get -u, we only update the Go language version in a fixed cadence to keep the impact of this predictable. For example, we have a bunch of Docker images and other infrastructure that all need to be upgraded when one of our modules suddenly bumps their Go language version. When a dependency suddenly uses a higher Go language version, we have to manually revert the upgrade of this dependency, which has now been happening with https://github.com/antlr4-go/antlr.
Note that, since Go 1.21, the go command forcibly upgrades the Go version in a module to be the maximum version of its dependencies (source), which is probably why this problem only started popping up recently.
See also these discussions on Reddit and StackOverflow.
As @mpsijm pointed out, I don't think
I keep the runtime at the latest version of Go whenever we make a new release.
is a good strategy as it forces all downstream dependants to upgrade.
We know that Go 1.22.x has security fixes over Go 1.21 - so we should upgrade.
At that time, that was not true. The Go team provides security fixes until there are two newer releases.
I think maintaining the same schedule would be a reasonable approach. Currently, that would mean staying at 1.22 until 1.25 is released (and upgrading to 1.23 then).
You can make your own fork, but not upgrading Go isn’t rational really
On Sat, Apr 19, 2025 at 16:26 Lukas Schmierer @.***> wrote:
As @mpsijm https://github.com/mpsijm pointed out, I don't think
I keep the runtime at the latest version of Go whenever we make a new release.
is a good strategy as it forces all downstream dependants to upgrade.
We know that Go 1.22.x has security fixes over Go 1.21 - so we should upgrade.
At that time, that was not true. The Go team provides security fixes until there are two newer releases.
I think maintaining the same schedule would be a reasonable approach. Currently, that would mean staying at 1.22 until 1.25 is released (and upgrading to 1.23 then).
— Reply to this email directly, view it on GitHub https://github.com/antlr/antlr4/issues/4663#issuecomment-2816888837, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ7TMDAV73KW5CERMDAHTD22LEQBAVCNFSM6AAAAAB3O777VOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMJWHA4DQOBTG4 . You are receiving this because you were mentioned.Message ID: @.***> lschmierer left a comment (antlr/antlr4#4663) https://github.com/antlr/antlr4/issues/4663#issuecomment-2816888837
As @mpsijm https://github.com/mpsijm pointed out, I don't think
I keep the runtime at the latest version of Go whenever we make a new release.
is a good strategy as it forces all downstream dependants to upgrade.
We know that Go 1.22.x has security fixes over Go 1.21 - so we should upgrade.
At that time, that was not true. The Go team provides security fixes until there are two newer releases.
I think maintaining the same schedule would be a reasonable approach. Currently, that would mean staying at 1.22 until 1.25 is released (and upgrading to 1.23 then).
— Reply to this email directly, view it on GitHub https://github.com/antlr/antlr4/issues/4663#issuecomment-2816888837, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ7TMDAV73KW5CERMDAHTD22LEQBAVCNFSM6AAAAAB3O777VOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMJWHA4DQOBTG4 . You are receiving this because you were mentioned.Message ID: @.***>
Honestly, I do not have a opinion about this strong enough for going into a discussion. Still I feel you did not address any of the arguments. Nevertheless, thank you for your work in open-source!
Any chance you can have a look at https://github.com/antlr/antlr4/pull/4688? I would really like to drop that golang.org/x/exp/slices from my project (without my own fork)