PostGIS 3.6.0rc2 Released

[Greg Troxel]

Sandro Santilli <strk at kbt.io> writes:

> Tip for packagers: `postgis install-extension-upgrades` (without any
> argument) will install upgrades from ANY version found in the default
> PostgreSQL service.
>
> Maybe we should make this the default for `make install`, rather
> than having it default to install upgrades from a manually-edited
> list of known older versions ...

The problem is that we're trying to address multiple things at once and
I don't think they can really be reconciled.

For packaging, the build is supposed to be deterministic.  Ideally, it
would be reproducible.  The same set of files should be installed, with
the same contents, regardless of the state of the running system.
(Packaging systems will enforce that prereqs are there, but I mean
whether postgresql has been initialized, whether the server is running,
or whether postgis has been installed in any database.)

For sanity, we should not install files per alpha/beta/rc of old
versions.

For user convenvience, just doing the simple upgrade incantation should
succeed, when the previous upgrade was to any released version or to a
pre-release associated with the currently installed version.


Thus I don't think it's ok to query all the datbases install extra stuff
at make install time.


I think the key question is whether we believe that it's ok to run an
ugprade using the ANY script when there is no specific path, as seems to
be the case now.   My sense is that there's some theoretical discomfort
of needing different scripts, but right now upgrade is drop/create.

A way out (not for 3.6.0 of course) might be

  1) Ignore alpha/beta/rc when searching for an upgrade file.  This
  closes off the possibility that you need different scripts for these
  cases.

  2) Allow ugprading from 3.6.0 to 3.6.0.

or perhaps

  1A) Search for alpha/beta/rc first, and if not found just search again
  without it.

  1B) Search for specific version upgrade files and if not found run the
  generic.  Drop all the files that are no longer necesary given this
  rule.


There are larger changes, like deciding that upgrade is just running the
upgrade script which does drop/create of functions etc., and there are
no other mechanisms.  But those seem more fraught, and not necessary to
solve the current pain.


It's also possible that I had some local issue or confusion on my part,
but it's definite that there's a lot of upgrade file coming and going,
creating work for matitnainers and packagers -- work that I suspect is
benefitting almost nobody, perhaps really nobody.