> On 4 Apr 2024, at 01:24, Michael Paquier <mich...@paquier.xyz> wrote: > > On Wed, Apr 03, 2024 at 01:38:50PM -0400, Tom Lane wrote: >> The discussion we had last year concluded that we were OK with >> dropping 1.0.1 support when RHEL6 goes out of extended support >> (June 2024 per this thread, I didn't check it). Seems like we >> should have the same policy for RHEL7. Also, calling Photon 3 >> dead because it went EOL three days ago seems over-hasty. > > Yeah. A bunch of users of Photon are VMware (or you could say > Broadcom) product appliances, and I'd suspect that quite a lot of them > rely on Photon 3 for their base OS image. Upgrading that stuff is not > easy work in my experience because they need to cope with a bunch of > embedded services.
That's true, but Photon3 won't package new major versions of PostgreSQL (the latest RPM is 13.14). Anyone who builds v17 on Photon 3 on their own can just as well be expected to build an updated OpenSSL no? This is equivalent to RHEL7 which was discussed elsewhere in this thread. If we are going to pin version dependencies for postgres X to available OS release packages then it, IMHO, is reasonable to be for OS's that realistically will package X (either by the vendor or a trusted external packager like PGDG). It's possible, but not guaranteed, that RHEL8 ships v17 packages in ther Application Streams Life Cycle model, they have packaged v15 so far with retirement in 2028 so it seems likely there will be another package to retire in 2029 when RHEL8 finally goes away (whether that will be v16 or v17 is also speculation). Thus, pinning on 1.1.1 is grounded in packaging reality, even though I sincerely hope that noone who isn't paying for support is running 1.1.1 now, let alone in 4 years from now. -- Daniel Gustafsson
