You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: