Bump minimum Go version to v1.22, rework CI matrix

[bgentry]

This bumps our CI to run the 4 most recent Postgres versions (v17, v16, v15, v14) against with the latest Go version (v1.23), and to run the previous Go release (v1.22) against the newest Postgres version. In doing so, we achieve better coverage on Postgres versions without having a bloated CI matrix of all possible combinations.

It also bumps our minimum Go version from v1.21 to v1.22. This continues our target of supporting the 2 most recent major Go versions, and expands CI to ensure we work on the 4 most recent PG versions.

[mfridman]

Thanks for maintaining the version updates! I'm curious about the decision to drop postgres 14 support - is this driven by specific newer features you need, or a general policy of supporting the most recent 3 major versions?

Postges 14 is still in its supported lifecycle (roughly midway through) and remains a commonly deployed version across major cloud providers, which typically lag behind latest releases.

[bgentry]

@mfridman There's no actual changes being made which will affect support for older Postgres versions and I don't believe any are coming soon. Honestly it's mainly a question of keeping the CI matrix in check. I should update the PR and description to make it clear this isn't actually dropping support for any Postgres versions, just changing CI.

In the case of Go, there are actually some things from newer Go versions that we'd like to start depending on soon.

[brandur]

Pulling PG 15 out of CI is effectively dropping support for it because you won't notice if you start using a new feature that 15 doesn't support, but 16+ does. Unlike Go, people still find it really hard to keep up-to-date on the latest versions of Postgres, so to keep more of them supported, it probably behooves us to keep running against Postgres versions we want to support.

To keep the build sustainable, I wonder if what we do is switch the build to use an N + M model instead of an N * M model. So you run all versions of supported Postgres on the latest Go version (1.23 currently), then all supported Go versions against Postgres 17.

Instead of having [1.21,1.22,1.23] * [14, 15, 16, 17] = 12 build jobs, you get [1.21, 1.22, 1.12] + [14, 15, 16, 17] = 7 jobs, which seems more manageable.

[bgentry]

@brandur Yeah, that makes a lot of sense. It's pretty unlikely that we'll encounter a bug that only exists on a specific Go/Postgres version combo anyway. We may need to restructure the CI slightly to make this easy but I'm onboard with that.

[mfridman]

@brandur summarized it quite nicely. My main concern about dropping versions from CI was around keeping the project honest about the intended supported postgres versions. It's quite easy to pull in a new feature not to realize it means bumping the minimum version.

I was going to suggest pretty much the same approach, reducing the matrix from all Go/postgres versions toward an additive testing matrix.

ps. No issues around Go versions, mainly just the postgres ones ✌️.

[mfridman]

I see in the docs you do specify:

River is tested using the three most recent major versions of PostgreSQL.

So my comment may be moot in terms of keeping postgres 14 around in CI. I suppose it is up to the individual projects to test River to ensure compatibility with their minimum postgres version policy.

If River introduces features that depend on newer postgres features, downstream projects have options:

1. Upgrade their postgres version requirement (often challenging, because it may be a dependency outside the project control)
2. Pin to an earlier River version that matches their postgres constraints
3. Skip/conditionally use features that require newer postgres versions

I appreciate this is the nature of software and support ya'll focusing River's testing on postgres versions that align with your maintenance goals.

[bgentry]

This was my first time setting up an Actions matrix config that explicitly listed the chosen combinations: https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/running-variations-of-jobs-in-a-workflow#expanding-or-adding-matrix-configurations

No other changes required 🙌

[brandur]

Great! lgtm.