[postgis-devel] PSC Vote: Drop support for GEOS 3.7 in PostGIS 3.5.0

[Greg Troxel]

Regina Obe via postgis-devel <postgis-devel at lists.osgeo.org> writes:

> GHA is testing 3.8, 3.9., 3.10, 3.12, 3.13
>
> Debbie/Winnie/Berries I think are all testing GEOS main - 3.13
>
> I think a good rule of thumb, is that our in-development PostGIS should
> support only non-EOL'd GEOS.  As to whether we support all or some, I guess
> would be a debatable question.

>From the pkgsrc viewpoint, geos is at 3.12, and thus I only care that
the current postgis stable release builds against that.

Of course postgis trunk also has to be ok with geos trunk, and if
postgis release becomes not ok with geos trunk, we need to make sure we
are never in a situation where postgis release fails with any recent
geos release.  But I think that's all ok.

The real question lurking here is how do we feel about LTS packaging?
Those systems have the odd situation of wanting to have all old software
installed but simultaneously expecting to build new versions of any
particular program.  This tends to lead to "FooOS X, released in 2016,
but still supported for security fixes until 2026, has geos [ancient],
but people want to build the latest postgis release -- without first
building geos -- so please keep support", and I think that's
unreasonable.  (My view is that if you choose LTS, you are choosing old
software, and you can run the postgis that is part of the LTS system.)

So to me the issue isn't really about having to keep supporting old geos
because the geos project is willing to maintain bugfixes on old
branches.  It's choosing between trying to accomodate LTS, and expecting
that a new postgis release will have a relatively recent geos to build
against.

All in all, I lean to

  postgis trunk at all times, and postgis releases on release date
  should

    build against any version of a dependency that was the current
    generally-recommended stable release as of two years ago, and any
    more recent stable release.  (This implies a point release if there
    is a new incompatible geos release after a postgis release.)

    for compilers and language support, same, but instead 4-5 years
    (because those are vastly harder to swap in)

  postgis trunk at all times should build against geos trunk.  The
  most recent stable branch of postgis probably should build against
  geos trunk also

This avoids "postgis should build on LTS packging systems" but also
allows a fair bit of slack so that we don't have "postgis builds only on
systems that are super up to date".

I don't mean the converse of my suggestion; if continuing to build with
geos older than 2 years causes little enough pain, that's fine.

By my suggestion above, it's necessary to build against geos 3.10
(2021-10), 3.11, 3.12 and trunk.  So dropping 3.7 is more than ok.  The
policy of regularly dropping geos releases that are EOL makes sense,
given that a geos release going EOL happens more than 2 years after the
first release of a new generally-recommended release.