On Thu, Sep 7, 2023 at 11:44 PM Daniel Gustafsson <daniel@yesql.se> wrote:
> > On 7 Sep 2023, at 13:30, Thomas Munro <thomas.munro@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.