[postgis-users] Newest PostGIS code with old PostgreSQL major versions

[Regina Obe]

I think Paul answered all the questions beautifully.  I've added one
additional comment to the below

> > It might be "safer" for them to stick with PostGIS 2.4 stable releases
> > on their PostgreSQL 10 fleet, and upgrade PostGIS around the same time
> > as when they upgrade to the latest major version of PostgreSQL? (Which
> > should happen within the next year, since PG 10 only has about a year
> > of official lifetime remaining, similar to PostGIS 2.4.)
> >
> > But maybe I'm reading too much into this policy and the maintenance of
> stable branches, and maybe the PostGIS community would encourage
> everyone to run the latest available PostGIS major version even on very
old
> versions of PostgreSQL? Also, the actual risk of issues     with running
recent
> PostGIS code against really old PostgreSQL versions might not be that high
in
> practice.
> 
> I think in general you are perhaps over-reading into the policy or
imagining
> the implications of cross-version issues. In general the extension API has
> been stable/static for so long that changes to PgSQL just don't affect us
a lot,
> at least at a functional "how things work" level.
> 
> P.
> 

Yes we would like all users to be running the highest version of PostGIS
that is supported for a given PostgreSQL release.
Some bug fixes are simply too difficult (both in terms of possible
destabilization and amount of differentlal code) to backport to older
versions.
But we understand there are very practical reasons why some people cannot
run with the newest version we support for a PostgreSQL release.
The main issue is with upstream dependencies.

Our versions are reliant on GEOS, Proj, GDAL, and SFCGAL release cycles.
If you are running an older version of PostgreSQL chances are you are
running on older versions of Proj, GEOS, and GDAL too.
There are only so many versions of those that we can support.  Those being
often system distributed libraries. Proj in particular has many breaking
changes.  GEOS and GDAL mostly tend to just add features (except of late
with GEOS where there are behavioral changes). PostgreSQL packagers are
often at the mercy of upstream packagers.

E.g. You can't be running GEOS 3.5, Proj 4.8 on PostGIS 3.1 for example.

So in addition of the hassle of IFDEFing out features of a PostgreSQL older
release that we are offering in a new release, we also consider the
likeliness that such an old system would have new enough GEOS / Proj to work
with new changes.  GDAL has never been too much of an issue as far as
versioning is concerned for us since it mostly adds new features and many of
which are transparent to us. It is even less so now that we've split out
postgis_raster from postgis so it's no longer a requirement to get extension
support.  SFCGAL isn't an issue versioning wise for us and is not a required
dependency either.

[Regina Obe]