[postgis-devel] Postgis 3.1 minimum requirements update

[rmrodriguez at carto.com]

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.


> Users do not;
> they have what their packaging system provides.  I view LTS as not
> relevant for new postgis (after all the LTS should have old postgis,
> presumably what LTS people want), but I think it's important to look to
> packaging systems/distributions that people run to see what the
> situation is.

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.

> There needs to be some benefit, such as in terms
> of increased performance (for those building with a newer version, vs
> the same build without the deprecation).

Expending less time maintaining old releases so we can spend more time
adding new features or improving existing ones is a benefit.


> 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.


> '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.



On Mon, Nov 11, 2019 at 4:27 PM Regina Obe <lr at pcorp.us> wrote:
> So that said I'm not strongly opposed to making it the minimum.

I'm not proposing to make GEOS 3.8 the minimum, just the recommended one to
use alongside Postgis 3.1.


[1] https://www.postgresql.org/support/versioning/

-- 
Raúl Marín Rodríguez
carto.com