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