[postgis-devel] Postgis 3.1 minimum requirements update

[Greg Troxel]

rmrodriguez at carto.com writes:

> On Mon, Nov 11, 2019 at 3:55 PM Greg Troxel <gdt at lexort.com> wrote:
>> I don't think it's a good thing to increase requirements just for the
> sake of increasing them. So I object to the notion that having a
> tradition of increases is a good thing.
>
> We need to do this because both Postgis and Postgresql are releasing new major
> versions every year. The expected roadmap is as follows:
> - Postgis 3.1 is expected to be released in Sep-Oct 2020 and to be supported
> for 3 years (deprecation goes as: 2.3 during the end of 2019, 2.4 during 2020,
> 2.5 during 2021, 3.0 during 2022 and 3.1 during 2023).
> - Postgresql 9.5 will be supported until February 11, 2021 [1].
>
> This means that we already have to deal with an unsupported release of
> Postgres for over a year and a half and, if we didn't drop 9.5 for 3.1, then
> add another extra year where we maintain compatibility.
>
> There have been several times where I'd had to setup a VM with a very old
> version of Postgresql so I can check why something doesn't compile or some
> test has a different value. I don't want to see myself 5 years from now
> installing a decade old postgres.

Certainly there are reasons like this.    I really meant

  increasing minimum versions doesn't help users and sometimes makes
  things harder for them, so each increase should have a rationale
  explaining what the gain is

I typically see that people invovled in an area have very up-to-date
versions of everything relevant, so what's in distributions often seems
ancient to them.  But users tend to have somewhat older versions.

A further complexity is that the total graph of dependencies is
complicated, and there are also "foo needs bar<N" requirements, not
documented because the last release of foo predates bar N.  That's not
really postgis's problem, but requiring recent versions can raise these
issues (perhaps not in this case, as long as you don't require proj 6).

> IMO, if you are good with running an old Postgres you should also be good with
> running an old Postgis. Expecting to have a newer Postgis at the cost of
> increasing the maintenance burden is not ok.

I see that as shades of grey, and the question here is the cutoff.

>> Another benefit could be
>> better semantics, and another could be getting to remove significant
>> amounts of compat code.
>
> This is removing ~500 LOC, specially around internal caches where the code is
> duplicated just to be compatible with 9.5.

That and it being EOL sounds like a justification (which was absent in
the original propossal).

>> 'Recommended" in a vacuum is odd, because the standard approach is to
>> run the most recent release from a given project, eccept that after big
>> changes it is sensible to hold off 3-6 months.  And, releases that
>> withdraw APIs have a much longer time before they can be considered
>> generally recommended (e.g. proj).
>
> GEOS 3.8 c-API is a superset of 3.7, nothing was removed but it did include
> new features that we make use for better performance. This probably meant
> adding some extra ~150 LOC whitin multiple ifdefs, and I'd like to be able
> to get rid of them 3-4 years down the line, but we need to start by
> recommending people to update.

I suspect most people just use what their systems have, and if they have
to start hand-building a separate tree then they grumble and do it.

Certainly getting geos up to 3.8 seems like the thing to do.  It just
seems a bit rushed this month, but a year from now will clearly be past
due.