> On 21 Sep 2023, at 07:28, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Thomas Munro <thomas.munro@gmail.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