Skip to content

Update dependency.md for go version updates #5710

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.

Sign up for GitHub

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

Open
ankur22 wants to merge 5 commits into
base: master
Choose a base branch
from
+35 −1
Open

Update dependency.md for go version updates #5710

Changes from 2 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
85000c5
Update dependency.md for got version updates
ankur22 Mar 4, 2026
cd06b58
Add why we wait for the .1 release of Go
ankur22 Mar 9, 2026
6d984c9
Update Dependencies.md
ankur22 Mar 9, 2026
079b5b7
Update Dependencies.md
ankur22 Mar 9, 2026
80df34d
Update Dependencies.md
ankur22 Mar 9, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 35 additions & 1 deletion Dependencies.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -26,7 +26,41 @@ The latter also serves as a time to open/close issues that are related to the up

## Go versions

We aim to support a building of the k6 binary with the two latest versions of golang, which reflects the support [policy](https://go.dev/doc/devel/release#policy) of the Go team.
We aim to support building of the k6 binary with the two latest versions of golang as long as the latest version has at least `.1` path release. The support [policy](https://go.dev/doc/devel/release#policy) of the Go team details that they support the two latest versions.
Copy link
Contributor Author

@ankur22 ankur22 Mar 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand exactly why we need to wait for the.1 release? Have we had a bad experience in the past? Is it only to ensure that we work with a release which is most likely to work?

I'd like to add the reason for this decision so that it's clearer for future readers.

Copy link
Contributor

@codebien codebien Mar 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because it reduces the risk to bring into our systems a zero-day exploit, and on the other side we don't get any benefit from rushing on updating it.

Go is very regular with updates, and there is always a first patch after a few weeks from the major release. This is my reasoning about it.

Copy link
Contributor Author

@ankur22 ankur22 Mar 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, i see, but a zero day vulnerability can also live in an old version of an unsupported Go version such as 1.24, and there's a chance that the Go maintainers will not fix it... not sure what's best, but happy to go with what has worked so far 🙂

Copy link
Contributor

@mstoykov mstoykov Mar 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would argue there are multiple reasons. Some of which are more "why we do not release k6 binaries with 1.26 the day it comes out". And some of them are more "why we do not have 1 version of go we support" - so currently we will just support 1.25 and then we move to 1.26 and never have 2 versions.

In general they come down to - usually it is not worth it for us to jump as fast as it is released, and we have to do work to get there, so we might as well not just do it.

I would argue golang should be support 1.24 for a month or so after 1.26 is released, and if this was paid support they certainly would, but they are not 🤷 .

Some reasons (in no particular order):

  1. We do not care about features in new golang versions 99% of the time. As in practice we will now start using stuff from 1.25 - the stuff in 1.25 are interesting. 1.26 has new GC - maybe that will be nice, maybe not. But we do not have this case of "oh a new API we need it now"
  2. New versions (among potential security versions) usually have some very bad bugs that are really hard to catch especially on "not x86" machines - see the list in the milestone and see how many are arm or even just windows specific bugs. I do not really want to try to debug a regression from them.
  3. golangci-lint needs and upgrade on each major go update. They are now more on top of it then before - they release the same day. But we usually need to update a bunch of stuff along this otherwise our CI is broken.
  4. The version propagation through all the caches has also been a case where if we updated too fast, somebody somewhere hasn't built (yet) the docker image for 1.26 with the specific things we care about. Or it turns out one CI runner has it, the other still thinks it is not out. This arguably is GHA issues, but we are the ones that have failing CI.
  5. We usually want to test this more in GCk6 prod - which means that moving to this new go versions needs to happen in the correct part of the release cycle. Which given that 1.26.1 is planned for tomorrow already released, likely will be the next week or so.
  6. We do not really release with the old version - we just have our CI. Theoretically we can drop the older version from CI and not know if we break something. Or we can just drop it after 1.26 was released so that we move to 1.25 only for a time. This seems like a lot of work. Instead, we just wait for 1.26.1 and slow down some updates.

See #5702 for an already opened PR that bumps the go to see some of those in action.

The list of changes in 1.26.1 are for example a bunch of CVEs in 1.26 only, and some in 1.25.

p.s. I started writing this before .1.26.1 was released 😅 but apparently didn't click reply.

Copy link
Contributor Author

@ankur22 ankur22 Mar 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are good arguments for keeping the process as is. Thanks for the background. I'll try to add these in so that future readers know why we do what we do.


E.g.

1. If the latest Go version is 1.26, the Go team will support 1.25 and 1.26, dropping support for 1.24.
2. We will support Go versions 1.24, 1.25 and 1.26 until 1.26.1 is released.
3. When the Go team release version 1.26.1, they will still only support 1.25 and 1.26.
4. We will support Go versions 1.25 and 1.26, dropping support of 1.24.

### Why we wait for the `.1` patch release

We deliberately do not rush to adopt a new major Go release (e.g. 1.26.0) the day it
comes out. There are several reasons for this:

1. **No immediate feature need** -- we rarely depend on brand-new Go APIs. Features from
the previous release are typically sufficient, so there is no urgency.
2. **Early releases carry bugs** -- the `.0` release of a new Go version frequently
ships with regressions that are hard to catch, especially on non-x86 platforms
(ARM, Windows). We prefer not to debug those ourselves.
3. **Toolchain lag** -- golangci-lint and other CI tooling need their own updates for
each major Go release. Even when maintainers ship same-day support, our full CI
pipeline (linters, Docker images, GitHub Actions caches) may not be ready yet.
4. **Cache and infrastructure propagation** -- CI runners, Docker base images, and
various caches do not all pick up a new Go version simultaneously. Updating too
early leads to flaky or broken CI across different runners.
5. **Release-cycle alignment** -- Go version bumps in production (e.g. Grafana Cloud k6)
need to land at the right point in our own release cycle, which adds a scheduling
constraint.
6. **Reduces zero-day risk** -- the `.1` patch typically fixes CVEs that were introduced
in the `.0` release itself, so waiting a few weeks costs us nothing and lowers
security risk.

In practice, the `.1` patch lands only a few weeks after the major release, so the
delay is minimal while the risk reduction is significant.


## Exceptions

Expand Down
Loading