[postgis-devel] PSC Vote: Change PostGIS library name to drop the minor

[Mark Cave-Ayland]

On 28/08/17 16:47, Regina Obe wrote:

> As discussed in my last note:
> 
> https://lists.osgeo.org/pipermail/postgis-devel/2017-August/026297.html
> 
> 
> I would like to drop the minor version in the PostGIS library, but to still
> allow developers to run two versions of PostGIS in same PostgreSQL cluster
> if they want to , introduce a new configure switch
> 
> --use-minor-version
> 
> Which defaults to false for 2.4
> 
> This is ticketed here:
> https://trac.osgeo.org/postgis/ticket/3807
> 
> I know Paul grudgingly agreed with me at code sprint  and said he'd make the
> change  and strk was okay in IRC with a lot of BUT BUT BUTs.
> Dan at code sprint also expressed concern.
> 
> I'd like a formal +1 and in particular hear from packagers once and for all
> if they see an issue with this;
> 
> The reason for this change is as follows:
> 
> Most postgresql extensions do not version their library file name, as such
> it's much easier for upgrades to be done using pg_upgrade from one
> PostgreSQL version to next.
> 
> A lot of packagers do not like carrying more than one version of PostGIS for
> each PostgreSQL which means PostGIS users using packages can't easily
> pg_upgrade from one PostgreSQL to another
> and also leaves us with the onerous task of supporting newer versions of
> PostgreSQL on older PostGIS.  Which is a great maintenance burden.
> 
> By dropping the minor thence forward from PostGIS 2.4 on, the lib file will
> be simply called   postgis-2 (.so,.dll, whatever) and we will be more free
> to release as we need to without forward supporting new versions of
> PostgreSQL on old versions of PostGIS, which is becoming increasingly
> frustrating as rate of PostgreSQL change goes.
> 
> Note the PostGIS version would still be 2.4.0 or 2.4.1 etc, 
> so the  ALTER EXTENSION postgis UPDATE 
> 
> would still need to be done and align the scripts with the lib.
> 
> 
> If Per chance we make such a serious change to PostGIS lib by
> dropping/renaming critical function that the new .so could possibly crash
> the backend with old postgis scripts.  
> I highly doubt it (though strk thinks it's possible) and yet such a serious
> change does not require a dump reload of the database, we can have the new
> version be called postgis-2b.
> 
> 
> +1  for this change
> 
> 
> I'd really like to hear from packagers what they think of this idea, as this
> is being done mostly for them so they don't have to deal with users
> constantly complaining about how they can't do pg_upgrade.

I'm a -1 for this.  I agree with strk that this is definitely the wrong
time to be doing this just before a release, and given that this problem
has always existed rushing into a decision now makes little sense.

The different version number is there for a reason to indicate that the
behaviour between versions will have changed, and while I understand
that upgrading is often tricky I don't believe this is the right solution.

It strikes me the real issue is that something is missing from the
upgrade process (whether that is PostGIS and/or PostgreSQL) and the
focus on solving the issue should be placed there, and not on removing
important version information from the generated libraries.


ATB,

Mark.