Go runtime should not depend on Go 1.22 yet

[mpsijm]

@jimidle bumped the Go version to 1.22 in antlr4-go/antlr@4d7e188 (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.

[jimidle]

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 ***@***.*** <antlr4-go/antlr@4d7e188> (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 <#4663>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJ7TMCQ4HPTPR36MUUFJILZOICZJAVCNFSM6AAAAABLQCJ7DCVHI2DSMVQWIX3LMV43ASLTON2WKOZSGQZTCNZRG43TONA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mpsijm]

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 🙂

[jimidle]

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?

[mpsijm]

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.