Hi,
Currently we claim to support all versions of LLVM from 3.9 up. It's
now getting quite inconvenient to test changes on older releases with
single digit major versions, because they aren't available through
usual package channels on current distributions, and frankly it feels
like pointless busy-work to build those older versions from source
(not to mention that it takes hoooouuurrs to compile that much C++).
At the other end of the window, we've also been back-patching support
for the latest LLVM versions into all supported releases, which might
make slightly more sense, but I don't know.
For the trailing end of the window, would it make sense to say that
when PostgreSQL 17 ships, it doesn't need to support any LLVM versions
that are no longer available in the default package repositories of
current major distros?
I'm trying to understand the practical constraints. Perhaps a package
maintainer could correct me if I have this wrong. Distros typically
support a range of releases from the past few years, and then bless
one as 'default' by making it the one you get if you install a meta
package eg 'llvm' without a number (for example, on Debian 12 this is
LLVM 14, though LLVM 13 is still available). Having a default
encourages sharing, eg one LLVM library can be used by many different
things. The maintainer of the PostgreSQL package then chooses which
one to link against, and it's usually the default one unless we can't
use that one yet for technical reasons (a situation that might arise
from time to time in bleeding edge distros). So if we just knew the
*oldest default* on every live distro at release time, I assume no
package maintainer would get upset if we ripped out support for
everything older, and that'd let us vacuum a lot of old versions out
of our tree.
A more conservative horizon would be: which is the *oldest* LLVM you
can still get through the usual channels on every relevant distro, for
the benefit of people compiling from source, who for some reason want
to use a version older then the default on their distro? I don't know
what the motivation would be.
What reason could there be to be more conservative than that?
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.