On Thu, Sep 7, 2023 at 11:44 PM Daniel Gustafsson <dan...@yesql.se> wrote: > > On 7 Sep 2023, at 13:30, Thomas Munro <thomas.mu...@gmail.com> wrote: > > I don't like the idea that our *next* release's library version > > horizon is controlled by Red Hat's "ELS" phase. > > Agreed. If we instead fence it by "only non-EOL version" then 1.1.1 is also > on > the chopping block for v17 as it goes EOL in 4 days from now with 1.1.1w > (which > contains a CVE, going out with a bang). Not sure what the best strategy is, > but whichever we opt for I think the most important point is to document it > clearly.
I was reminded of this thread by ambient security paranoia. As it stands, we require 1.0.2 (but we very much hope that package maintainers and others in control of builds don't decide to use it). Should we skip 1.1.1 and move to requiring 3 for v17? Upstream says: "The latest stable version is the 3.2 series supported until 23rd November 2025. Also available is the 3.1 series supported until 14th March 2025, and the 3.0 series which is a Long Term Support (LTS) version and is supported until 7th September 2026. All older versions (including 1.1.1, 1.1.0, 1.0.2, 1.0.0 and 0.9.8) are now out of support and should not be used." I understand that some distros eg RHEL8 will continue to ship and presumably patch 1.1.1 until some date later than upstream's EOL, for stability and the benefit of people that really need it for a bit longer, but that's in parallel with their package for 3, right? New things should surely be able to require new things. I think we'd have to reject the argument that we should support it just because they ship it until the year 2030, or that upstream will support anything for $50,000/year. I mean, they only do that because some old apps need it, to which I say 40P01 DEADLOCK DETECTED.
