On 2020-Oct-16, Andres Freund wrote:
> A related question is whether it'd be time to prune the oldest supported
> LLVM version. 3.9.0 was released 2016-08-31 (and 3.9.1, the only point
> release, was 2016-12-13). There's currently no *pressing* reason to
> reduce it, but it is the cause of few #ifdefs - but more importantly it
> increases the test matrix.
Is there a matrix of LLVM versions supported by live distros? It sounds
like pruning away 3.9 from branch master would be reasonable enough;
OTOH looking at the current LLVM support code in Postgres it doesn't
look like you would actually save all that much. Maybe the picture
changes with things you're doing now, but it's not evident from what's
in the tree now.
> I'm inclined to just have a deterministic policy that we apply around
> release time going forward. E.g. don't support versions that are newer
> than the newest available LLVM version in the second newest
> long-term-supported distribution release of RHEL, Ubuntu, Debian?
It seems fair to think that new Postgres releases should be put in
production only with the newest LTS release of each OS -- no need to go
back to the second newest. But I think we should use such a criteria to
drive discussion rather than as a battle axe chopping stuff away.
