formalized support matrix for PG versions

[hunleyd]

SUMMARY

The collection should adopt a matrix of supported PG versions. Right now, there's no formal declaration of what PG versions are supported and the pipeline tests a few different versions but the answer to 'what versions of PG does this collection support?' is essentially 'all of them? ¯\_(ツ)_/¯'

As noted in this comment, we have places in the code that are marked as 'we do it this way because versions older than X don't support FOO' and yet, we don't actually test those older versions to ensure it works and we can't make optimizations in the code for fear of breaking old PG releases.

PROPOSAL

The PostgreSQL Global Development Group (PGDG) officially support every major version of PG for 5 years according to their version policy. I propose that this collection follow the currently supported PGDG releases.

An illustrative example based on this year's upcoming PG 15 release:

Year	Matrix
2022	15,14,13,12,11
2023	16,15,14,13,12
2024	17,16,15,14,13
2025	18,17,16,15,14
2026	19,18,17,16,15
2027	20,19,18,17,16

The table above shows the PG versions that would be tested via the pipeline to ensure compatibility. We would release a major version of the collection each year when the pipeline matrix is updated (maybe we bump the collection version number to match the PG release being supported? So adding support for PG 15 would give us community.postgresql-15.0.0. Food for thought.)

REASONING

This would allow us to drop/refactor old code on a regular basis and be free to take advantage of new PG features more easily. End users would gain a clearer understanding of what PG versions are tested in a given release, and if they need to continue supporting an older release, they could simply use a prior release that is known to support that version (e.g. in 2027 if they still needed PG 15 support they could simply use the collection release from 2026).

[keithf4]

This sounds good. I've followed a similar support pattern with pg_partman. I didn't go out of my way to make the extension not work with older versions; it still technically works back to PG 9.4 but I officially only support 10+. But if a feature or bugfix came out in PG that was not supported by a version older than that window, then I wouldn't hesitate to implement that feature and therefore break that backward compatibility at that time.

[pgguru]

This policy makes sense for me for new development/support; main question would be if/when there are some sort of security issues or bugs that affect older versions of the collections, are bugfixes released for the older versions as well, or we consider 5 years to be the maximum window of support for all of them? i.e., in 2027 we have a security issue with PG16, do we patch only community.postgresql-20.0.0, or release new versions for 20.0.0, 19.0.0, down to 16.0.0?

[hunleyd]

@pgguru, the security issue would have to be both for a specific PG version and in the collection code, right? Right now, we only support the current collection (main) and the prior (stable-1). I don't know that we'd really want to expand that without more people/automation, but that's a very good question.

[Andersson007]

@hunleyd thanks for bringing this up! @keithf4 @pgguru thanks for taking part in the discussion!

• I'm not sure if we should release a special major release each year to inform folks that we officially drop support of the latest EOL version of postgres. Feels a bit like an overkill to me, especially because dropping support doesn't necessarily mean the collection will stop working with that version. I'd suggest planning such things just for the next major release no matter when it'll happen maybe?
• We could plan dropping support of currently EOL versions in the next major release, i.e. 3.0.0 (create an issue and link it with the milestone). If we decide to do it, i would announce it now via the changelog.
• We should also define which versions of the connector the collection support (but this would require big changes in CI as we should test against supported connector versions too in this case)
• I would suggest, besides the current version, supporting 2 previous version of the collection. I.e. when we release 3.0.0, we'll backport bugfixes to stable-2 and stable-1 and release patch releases. When 4.0.0 is released, we'll backport to stable-3 and stable-2, and will stop backporting to stable-1, etc.

Any thoughts?

[hunleyd]

@Andersson007 :

* I'm not sure if we should release a **special** major release each year to inform folks that we officially drop support of the latest EOL version of postgres. Feels a bit like an overkill to me, especially because dropping support doesn't necessarily mean the collection will stop working with that version.

It'd be more about announcing support for the new release since, as you say, we aren't breaking old releases. I think it makes it easier for the community in that you can say 'PG N? Oh, that's supported in release X' instead of 'uh .. one of the X.X point releases, let me check the Changelog'. Just my $0.02

* We could plan dropping support of currently EOL versions in the next major release, i.e. 3.0.0 (create an issue and link it with the milestone). If we decide to do it, i would announce it now via the changelog.

That was why I wanted to get the community feedback on the idea now. This issue is going to be in this week's Bullhorn, and I figured I'd also post it to Reddit to get feedback.

* We should also define which versions of the connector the collection support (but this would require big changes in CI as we should test against supported connector versions too in this case)

I concur. Was trying not to bite off too much in one go and figured we'd tackle that next since I think it's a bigger LoE

* I would suggest, besides the current version, supporting 2 previous version of `the collection`. I.e. when we release 3.0.0, we'll backport bugfixes to stable-2 and stable-1 and release patch releases. When 4.0.0 is released, we'll backport to stable-3 and stable-2, and will stop backporting to stable-1, etc.

WFM

[hunleyd]

The votes look like:
GH - 7 for, 0 against
/r/ansible - 15 for, 0 against
/r/postgresql - 7 for, 0 against

Sounds like a plan :)

I'll get to working on this soon.