[postgis-devel] Postgis 3.1 minimum requirements update

[Greg Troxel]

"Darafei \"Komяpa\" Praliaskouski" <me at komzpa.net> writes:

>>
>>
>> > Minimum PG version: 9.6 (was 9.5)
>> ....
>> What's the gain of changing this, to offset the pain caused by people
>> using 9.5?
>>
>
> PostGIS 3.1 is going to be released around the time 9.5 will become End of
> Life.

Fact noted, but making postgis not build with 9.5 is not an actual
benefit :-) Unless it makes code in postgis simpler, it's just telling
people "you ought to know better than to run things that are technically
eol and we are going to break the build of postgis for you so you
notice".

Would anything change, other than the acceptable version in the build
system?  If not, what's the gain?

(I realize there are testing complexities, but the postgis project
surely does not run tests will all combinations of versions of
depdendencies that meet minimum requirements.)

>> Recommended GEOS version: 3.8 (was 3.7)
>>
>> '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).
>
> Setting GEOS 3.8 as minimum (instead of "recommended") will let us lose a
> large amount of code that was shifted into it from liblwgeom, including but
> not limited to MakeValid, and guarantee that all the users get all the
> functionality including the Frechet distance.
> It will also let us ship Coverage Union as a function without the "alas
> your distro maintainer built postgis without it" curse.
> We will still have some variablility because of upcoming GEOS 3.9/4.0, but
> keeping it at manageable level is generally a good idea.

I went to check what pkgsrc has nad thought it was 3.8.0, but no that's
my local tree with an update staged that I'm not 100% sure its prudent
to push to the world, and it's 3.7.3 actually in pkgsrc.

Looking it up, 3.8 was just released on October 10, just 32 days ago!
Setting that as a minimum seems really aggressive.  But, if there are
things in it that are necessary for postgis to work (where work, means
queries that work in the recommended build work in all builds), and
3.7.x doesn't allow those to work, I can see the point.

Definitely we should see what Bas thinks here.

> Previously I proposed to also bump GDAL to 2.1 and PROJ to 4.9 for PostGIS
> 3.0. This did not come through as it was rather late in previous cycle, but
> getting it (or a year in the future stricter) would be good. This also lets
> us remove some quirks.
>
> https://github.com/Komzpa/postgis/tree/ticket-4455

>From the packaging viewpoint, gdal 2.1 and proj 4.9 are INHO not a
problem.  Our current requirements for these are really old.  I don't
see anybody wanting to use gdal < 2.1 or proj < 4.9 without being in an
intentionally-ancient situation.

My impression is that most packaging systems have moved to at least proj
5.2, which is more or less not problematic in terms of depending
packages, and considering 6.  So failing on <4.9 seems unlikely to
bother anyone, and I could see it simplifying the code as proj has had
multiple API changes.

For gdal, I'd expect packaging systems to be at at least gdal 2.3 and
probably 2.4, and thinking about 3 (which might be linked to proj 6).

What benefit does requiring gdal 2.1 bring?  Is there conditional code
that would get deleted?