Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bump up Antrea Go build version for every Go minor release #6929

Open
antoninbas opened this issue Jan 15, 2025 · 0 comments
Open

Bump up Antrea Go build version for every Go minor release #6929

antoninbas opened this issue Jan 15, 2025 · 0 comments
Assignees
Labels
area/build-release Issues or PRs related to building and releasing

Comments

@antoninbas
Copy link
Contributor

In the past, we would only bump up the Go version used to build Antrea every other Go release.
For example, Antrea v2.1 uses Go 1.21, while Antrea v2.2 and v2.3 use Go 1.23. Originally, our intent was to reduce the maintenance burden by skipping every other version.
Note that we always pick up the latest patch version available for the specified Go minor version (specified in the go.mod) when building Antrea,
However, this puts us in the awkward situation where an Antrea minor release may still be maintained, while the Go version used to build that release it is no longer maintained. That means that new patch versions may use an unmaintained Go version (possibly suffering from CVEs), unless we backport the Go version upgrade to that release branch, which may involve resolving a fair amount of conflicts. At the moment, we are trying to release Antrea v2.1.1, but because the 2.1 release branch still uses Go 1.21, we are hitting a few CVEs that may be problematic for our users. Therefore we are working on backporting the upgrade to Go 1.23 to the 2.1 release branch: #6928

My proposal is to bump the Go version used in the main branch whenever a new Go minor version is released (instead of skipping every other minor version). Based on the release cycles for Golang and Antrea, with the proposed change, the problematic situation described here would either no longer be possible or would be much less likely. For example, the 2.1 release branch would currently be using Go 1.22, which is still maintained. Note that the proposed approach is also consistent with how Kubernetes handles new Go versions, as far as I can tell.

@antoninbas antoninbas added the area/build-release Issues or PRs related to building and releasing label Jan 15, 2025
@antoninbas antoninbas self-assigned this Jan 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/build-release Issues or PRs related to building and releasing
Projects
None yet
Development

No branches or pull requests

1 participant