Switch to go 1.18 and pin release-utils to v0.7.1 #904
Conversation
saschagrunert
force-pushed
the
release-utils
branch
from
355c8cc
to
abdcf21
Compare
|
I think we need to have go1.18 |
saschagrunert
changed the title
We should use the release versions rather than the commits on `main` to let dependabot update it automatically. Signed-off-by: Sascha Grunert <[email protected]>
saschagrunert
force-pushed
the
release-utils
branch
from
abdcf21
to
ed4c36e
Compare
Codecov Report
@@ Coverage Diff @@
## main #904 +/- ##
==========================================
- Coverage 47.86% 47.83% -0.04%
==========================================
Files 62 62
Lines 5461 5461
==========================================
- Hits 2614 2612 -2
- Misses 2559 2561 +2
Partials 288 288
Continue to review full report at Codecov.
|
|
I know this is merged now, but we need to agree on a go versioning strategy. I am of the mind that we should pin go.mod to the last supported release and then test against newer releases. When a go version deprecates, we then move up one release within go.mod. Either way, even if that is not seen as the correct approach, we right now we have some projects running go.1.17 (sigstore/sigstore) and others running go.1.18 I will put it on the community agenda for next week. |
|
As a side note, in Kubernetes we follow the principle of always using the latest available go version, because this allows us to update critical dependencies when they require a recent go version, too. |
|
The main driver for 1.18 has been the hashicorp dependencies that require it. |
Summary
We should use the release versions rather than the commits on
mainto let dependabot update it automatically.Release Note
NONE
Documentation
NONE