all: Bump supported Go versions to 1.19 and 1.20.

[Shaptic]

It's time 👀

Also, stop using specific versions so that we always used the latest patch version of a major release. Didn't this used to be the case?

[tsachiherman]

I'm a bit concerned that it's not as "safe".
i.e. existing code would stop working / work differently at some point, and we won't know why.
example for that is the govet tool; once in a while, it's being extended, and it starts generating new warnings. Having warning on new introduced code is always ok, but having existing code start failing ( without any hint why ) is a bit questionable.

[tsachiherman]

I do agree, though, that we should align with the latest. I'm not sure though if we want this to be automatic or not.

[Shaptic]

@tsachiherman hmm, can you explain what you mean about "existing code starts failing"? All of the CI checks pass with the new versions, incl. linting, so any future failures would have to come from new code.

[Shaptic]

(For context, we are committed to supporting the two latest major versions of Go, so this is something we do regularly with new releases [e.g. see #4499].)

[tsachiherman]

@tsachiherman hmm, can you explain what you mean about "existing code starts failing"? All of the CI checks pass with the new versions, incl. linting, so any future failures would have to come from new code.

sure. The CI checks are only when we actively trigger a build, not when a new go version is introduced.
so, if you have a PR that is failing, you wouldn't know if it's related to the go version or to the code in that PR.

[tsachiherman]

This isn't expected to be a common issue, but I've seen in happening before. ( specifically, between go 1.11.3 to 1.11.6, when the DNS SRV record processing logic was modified ).

[Shaptic]

Ah I see. That's an interesting point, but if it was definitively related to the version then you would see e.g. success on 1.19 and failure on 1.20, at least in places we have the matrix.

[tsachiherman]

How do you feel around using your pr as is, but also adding some validation that we're using a specific sub version. That way, we're always need to update that explicitly.

[mollykarcher]

If I understand your point Tsachi, your concern is that if we have "1.20" here and under the hood the version changes from 1.20.1 -> 1.20.2 which causes some test failures, it won't be obvious to the developer that the version changed at all, so it would be tough to nail down the cause for the failure. I get that, but it seems like it would be a pretty rare occurrence to have breaking changes come in with new patch versions.

This behavior mirrors what both quickstart and the package builders do, and I think we greatly benefit from being consistent here. But you could question whether or not we should be pinning versions in those places as well. However, I would argue against this because it could make our reaction to security patch updates easier; we could simply rebuild/redeploy the same version without updating any source code, rather that going through the entire bump/re-release/upgrade process.