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