Andres Freund <andres@anarazel.de> writes:
> 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.
> 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?
Meh. I do not think these should be mechanistic one-size-fits-all
decisions. A lot hinges on just how messy it is to continue support
for a given tool. Moreover, the policy you propose above is
completely out of line with our approach to every other toolchain
we use.
I'd rather see an approach along the lines of "it's time to drop
support for LLVM version X because it can't do Y", rather than
"... because Z amount of time has passed".
regards, tom lane
