...because I don't see one yet, and upcoming things like the Python test port are going to need clarity in advance, and I wanna stir up trouble right before I go eat lunch.
= Background = The most recent (mailing list) discussions I am aware of are at [1] https://postgr.es/m/16098.1745079444%40sss.pgh.pa.us (Python) [2] https://postgr.es/m/42e13eb0-862a-441e-8d84-4f0fd5f6def0%40eisentraut.org (Meson) The discussion in [2] ended with a growing consensus that we need _a_ policy, and Andres proposed a framework of one, but I don't think one was actually chosen. (If I missed that somewhere on the list, or at an in-person meeting, I apologize. Most of this email is moot if that's the case.) The partial list of dependency versions for PG19 is here, and if you know what's pinning one of the blank rows, please consider filling it in: https://wiki.postgresql.org/wiki/Minimum_Dependency_Versions But I intend this thread to be about PG20, which will release next year (2027) and will presumably be supported until 2032. = My Votes = For PG20, I want to drop support for RHEL 8 (and prior -- we still have CentOS 7 machines testing HEAD in the buildfarm). For me, the most important reason is OpenSSL, because upstream has already reached 4.0 and we still can't drop code written for 1.1.1. An additional reason is Python 3.6, which was EOL in 2021; I'd like to avoid pinning that for another six(!) years. It looks like ninja/meson get a boost too. RHEL 8 users in the paid Maintenance Support window (ending 2029) will still be able to use PG19 for its entire lifetime. And the maintenance window for RHEL 7 is long gone. People can update their machines if they want shiny new features. Cherry-picking from Tom's email on the topic in [2], which may not be representative of his opinion today: > Maybe we could compromise on > > If the expected PG major version release date is more than N years > after the end of full support for an LTS distribution, that OS > version does not need to be supported. > > Defining it relative to "full support" also reduces questions about > whether extended support means the same thing to every LTS vendor. > > If we set N=2 then we could drop RHEL8 support in PG 19; if we > set N=3 then it'd be PG 20 (measuring from end of full support > in May 2024). I'd be okay with either outcome. I propose that we adopt N=2. I think we should have stopped supporting RHEL8 this year (our yum repos won't be shipping PG19 builds for RHEL8). But I won't complain if consensus forms on N=3; I think it's just important that we arrive at some agreement on getting rid of RHEL 8. --Jacob
