[postgis-devel] PSC Vote: Drop the minor in the postgis lib files

[Regina Obe]

Okay

> -----Original Message-----
> From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On
> Behalf Of Paul Ramsey
> Sent: Friday, September 14, 2018 11:49 AM
> To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
> Subject: Re: [postgis-devel] PSC Vote: Drop the minor in the postgis lib files
> 
> Any chance we could defer this one for face-to-face at sprint?
> 
> P
> 
> > On Sep 14, 2018, at 8:43 AM, Regina Obe <lr at pcorp.us> wrote:
> >
> > As mentioned before, though I forget if I got enough consensus to move
> > forward.
> >
> > I would like the minor of our lib file dropped in 3.0
> >
> > So that would mean
> >
> > 1) The installed lib file would be called  postgis-3 for 3.0, 3.1, 3.2  etc.
> > rtpostgis-3, postgis_topology-3 etc.
> > 2) The extension version would still contain the minor and micro as it
> > always has
> > 3) We would have a special switch in the .configure (by default turned
> > off), for development purposes called:
> >
> > --add-lib-minor  (that's my current favorite, though I'm open to
> > changing the name)
> >
> > This is mostly a development switch so developers can test say 3.0,
> > 3.1 in the same postgres instance (different databases) or for those
> > folks who want to run both and compile their own postgis.
> >
> >
> > -- What this solves
> >
> > 1) Much smoother pg_upgrade for users.  Right now whenever anyone
> > needs to use pg_upgrade, they need to install  an older postgis in
> > their newer install or use a hack to symlink the old name to the new
> > name
> > 2) By dropping the Minor, this pain goes away, and also means we don't
> > need to always support newer versions of PostgreSQL on older versions
> > of PostGIS as long as we release before the PostgreSQL version.
> >
> >
> > -- What we give up
> > 1) We need to be very careful not to remove C functions exposed in SQL
> > scripts that are referenced in older versions of the same major.  So
> > that means 3.1 can't remove any C - SQL API exposed functions we
> > introduced in 3.0, though it can add more.
> >  If we need remove said functions, we need to stub those functions
> > with an error code but keep the signature.
> >
> > The reason why this is necessary is that during pg_upgrade, the
> > upgrade script recreates the extension from what was already installed
> > by installing each function, so if during install, it hits a function
> > that can't find it's C-function mate, upgrade will fail.
> >
> > Note helper functions we have that just get called internally by our
> > other functions we can rename all we like.
> >
> >
> > +1 to push forward (after all the bots are happy again).
> >
> >
> >
> > Thanks,
> > Regina
> >
> >
> > _______________________________________________
> > postgis-devel mailing list
> > postgis-devel at lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/postgis-devel
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel