Update dependency.md for go version updates

[ankur22]

What?

Updates the dependency.md file with when we update Go version in the go.mod file.

Why?

To avoid confusion and make it clear with an example.

Checklist

• I have performed a self-review of my code.
• I have commented on my code, particularly in hard-to-understand areas.
• I have added tests for my changes.
• I have run linter and tests locally (make check) and all pass.

Checklist: Documentation (only for k6 maintainers and if relevant)

Please do not merge this PR until the following items are filled out.

• I have added the correct milestone and labels to the PR.
• I have updated the release notes: link
• I have updated or added an issue to the k6-documentation: grafana/k6-docs#NUMBER if applicable
• I have updated or added an issue to the TypeScript definitions: grafana/k6-DefinitelyTyped#NUMBER if applicable

Related PR(s)/Issue(s)

[ankur22]

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.

[codebien]

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.

[ankur22]

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 🙂

[mstoykov]

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.

[ankur22]

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.

[inancgumus]

🚀