proposal: drop support for older go versions

[costela]

Chi currently supports go down to 1.14, which has been EOL for almost 4 years.

This means keeping "code smells" around (e.g. ioutil) and blocking access to some newer features (e.g. ResponseController).

I propose bumping the minimal version to allow for more aggressive deprecations and feature adoption.

Concretely, I'd propose matching go's support policy of "latest+2", but would be happy with any other such dynamic approach, so that there's

1. a clearly defined expectation of support
2. no need to periodically rehash the support discussion

WDYT?

[VojtechVitek]

Good points, I agree. I'd vote to drop support for Go 1.17 and older.

Go 1.18 would be enough to replace the deprecated io/ioutil functions, and so we could start using net/netip pkg.

[VojtechVitek]

However, ResponseController was added in Go 1.20. Would it be too aggressive to drop support for Go 1.18 and Go 1.19 too?

[VojtechVitek]

I'd propose matching go's support policy of "latest+2", but would be happy with any other such dynamic approach, so that there's

This is actually a great idea. Even if we go for "latest+4" to be more conservative, we'd still support Go 1.19 as of today (and Go 1.20 in Feb '25), which should be fine for most of the users. 👍

[c2h5oh]

I think we should go a little bit past EOL cutoff, because there are some environments that are slow to adopt new version of go and even slower to remove support for older ones, most notably Google App Engine.

Latest +3 or +4 sounds like a reasonable compromise.

[costela]

I think we should go a little bit past EOL cutoff, because there are some environments that are slow to adopt new version of go and even slower to remove support for older ones, most notably Google App Engine.

Just FTR, it seems app engine isn't that far from the upstream support timeline. Latest 1.23 is still in preview, but 1.20 has already been EOLd:

And just as a devil's advocate, I see two more options:

• Telling users on older runtimes to stick with a slightly older chi version if runtime support is more important than new features.
• Supporting latest+2 on the master, but keeping the door open for security-fix releases up until +X (via minor releases from other branches e.g. 5.1.x).

But in summary, yes, I'd be totally ok with just +4 overall as well.

[pkieltyka]

good discussion. I think latest +4 is a good place to be in general. I’d say for short term if we broke the rule to +3 so we could bump up to 1.20 given that 1.24 is coming out soon and we’d then be at latest+4.

And for any Go versions older, they can use an older tag of chi.