Re: Guiding principle for dropping LLVM versions? - Mailing list pgsql-hackers

Here are some systematic rules I'd like to propose to anchor this
stuff to reality and avoid future doubt and litigation:

1.  Build farm animals testing LLVM determine the set of OSes and LLVM
versions we consider.
2.  We exclude OSes that will be out of full vendor support when a
release ships.
3.  We exclude OSes that don't bless an LLVM release (eg macOS running
an arbitrarily picked version), and animals running only to cover
ancient LLVM compiled from source for coverage (Andres's sid
menagerie).

By these rules we can't require LLVM 14 for another year, because
Ubuntu and Amazon Linux are standing in the way*:

    animal     |  arch   | llvm_version |   os   | os_release | end_of_support
---------------+---------+--------------+--------+------------+----------------
 branta        | s390x   | 10.0.0       | Ubuntu | 20.04      | 2025-04-01
 splitfin      | aarch64 | 10.0.0       | Ubuntu | 20.04      | 2025-04-01
 urutau        | s390x   | 10.0.0       | Ubuntu | 20.04      | 2025-04-01
 massasauga    | aarch64 | 11.1.0       | Amazon | 2          | 2025-06-30
 snakefly      | aarch64 | 11.1.0       | Amazon | 2          | 2025-06-30
 sarus         | s390x   | 14.0.0       | Ubuntu | 22.04      | 2027-06-01
 shiner        | aarch64 | 14.0.0       | Ubuntu | 22.04      | 2027-06-01
 turbot        | aarch64 | 14.0.0       | Ubuntu | 22.04      | 2027-06-01
 lora          | s390x   | 15.0.7       | RHEL   | 9          | 2027-05-31
 mamushi       | s390x   | 15.0.7       | RHEL   | 9          | 2027-05-31
 nicator       | ppc64le | 15.0.7       | Alma   | 9          | 2027-05-31
 oystercatcher | aarch64 | 15.0.7       | Alma   | 9          | 2027-05-31

Ideally more distros would be present in this vacuum-horizon decision
table, but I don't think it'd change the conclusion: 10 is the
trailing edge.  Therefore the attached patch scales back its ambition
to that release.  Tested on LLVM 10-18.

If I pushed this we'd need to disable or upgrade the following to
avoid failure in configure on master:

   animal    |        arch        | llvm_version |   os   | os_release
| end_of_support
-------------+--------------------+--------------+--------+------------+----------------
 dragonet    | x86_64             | 3.9.1        | Debian | sid        |
 phycodurus  | x86_64             | 3.9.1        | Debian | sid        |
 desmoxytes  | x86_64             | 4.0.1        | Debian | sid        |
 petalura    | x86_64             | 4.0.1        | Debian | sid        |
 mantid      | x86_64             | 5.0.1        | CentOS | 7
| 2019-08-06
 idiacanthus | x86_64             | 5.0.2        | Debian | sid        |
 pogona      | x86_64             | 5.0.2        | Debian | sid        |
 cotinga     | s390x              | 6.0.0        | Ubuntu | 18.04
| 2023-06-01
 vimba       | aarch64            | 6.0.0        | Ubuntu | 18.04
| 2023-06-01
 komodoensis | x86_64             | 6.0.1        | Debian | sid        |
 topminnow   | mips64el; -mabi=32 | 6.0.1        | Debian | 8
| 2018-06-17
 xenodermus  | x86_64             | 6.0.1        | Debian | sid        |
 alimoche    | aarch64            | 7.0.1        | Debian | 10
| 2022-09-10
 blackneck   | aarch64            | 7.0.1        | Debian | 10
| 2022-09-10
 bonito      | ppc64le            | 7.0.1        | Fedora | 29
| 2019-11-26

*Some distros announce EOL date by month without saying which day, so
in my data collecting operation I just punched in the first of the
month, *shrug*