Re: Guiding principle for dropping LLVM versions?

> On 21 Sep 2023, at 07:28, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
>> I wonder if there is a good way to make this sort of thing more
>> systematic. If we could agree on a guiding principle vaguely like the
>> above, then perhaps we just need a wiki page that lists relevant
>> distributions, versions and EOL dates, that could be used to reduce
>> the combinations of stuff we have to consider and make the pruning
>> decisions into no-brainers.

As someone who on occasion poke at OpenSSL compat code I would very much like a
more structured approach around dealing with dependencies.

> Thus, I think it's worthwhile to spend effort on back-patching
> new-LLVM compatibility fixes into old PG branches, but I agree
> that newer PG branches can drop compatibility with obsolete
> LLVM versions.

+1

> LLVM is maybe not the poster child for these concerns -- for
> either direction of compatibility problems, someone could build
> without JIT support and not really be dead in the water.

Right, OpenSSL on the other hand might be better example since removing TLS
support is likely a no-show. I can see both the need to use an old OpenSSL
version in a backbranch due to certifications etc, as well as a requirement in
other cases to use the latest version due to CVE's.

> In any case, I agree with your prior decision to not touch v11
> for this. With that branch's next release being its last,
> I think the odds of introducing a bug we can't fix later
> outweigh any arguable portability gain.

Agreed.

--
Daniel Gustafsson