<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" data-hsystem="true"></head>
<body><style>p{margin: 0;padding: 0;}
</style>
<p style="margin: 0; padding: 0;"> </p>
<p style="margin: 0; padding: 0;">PostGIS PSC, Stakeholders, All -</p>
<p style="margin: 0; padding: 0;"> </p>
<p style="margin: 0; padding: 0;"> I believe there is a certain weight to the
conencted graph of components, that has to do with other implementors, technical
strength,</p>
<p style="margin: 0; padding: 0;">interoperability, luck, and other
factors..</p>
<p style="margin: 0; padding: 0;"> </p>
<p style="margin: 0; padding: 0;"> Specifically, a certain very large project
is re-writing their geometry handling with their own libraries, and rejecting
GEOS at the same time.</p>
<p style="margin: 0; padding: 0;">Therefore, GEOS is less of a stand-alone
component in the future, and due to packaging realities, is problematic for a
requirements chain.</p>
<p style="margin: 0; padding: 0;">Regina observed that "the way people are going
to get GEOS in the future is with GDAL" and I concur.</p>
<p style="margin: 0; padding: 0;"> </p>
<p style="margin: 0; padding: 0;"> So reduce or eliminate GEOS version
requirements, and focus on the GDAL version.<br>This is ironic, since initially
GDAL for PostGIS raster caused huge drag on the packaging efforts, due to
circular depends.</p>
<p style="margin: 0; padding: 0;">But in this proposed future, the PostgreSQL
version + GDAL version would be the markers, and the rest of the chain follows
.</p>
<p style="margin: 0; padding: 0;"> </p>
<p style="margin: 0; padding: 0;"> hth -Brian</p>
<p style="margin: 0; padding: 0;"> </p>
<p style="margin: 0; padding: 0;"> </p>
<p style="margin: 0; padding: 0;"><br>On Fri, 29 Sep 2017 16:28:31 +0000,
Darafei "Komяpa" Praliaskouski <me@komzpa.net> wrote:</p>
<blockquote style="border-left: 2px solid #000000; padding-right: 0px;
padding-left: 5px; margin-left: 5px; margin-right: 0px;">
<div id="html-message">
<div>Please don't hesitate to raise minimum versions to latest
released at the time of release.<br>If someone needs an older version, they are
free to comment out the checks and build at their own risk.<br>Otherwise we're
going to have distros with older versions of libraries, because "it's not
required to upgrade so let's not".<br><div> </div>
<div>If somebody updates postgis outside of their distro's release cycle,
they're doing it at their risk already, so no reason not to drag newer libraries
in. Usually they don't break too much ABI to postpone.</div>
</div>
<br><div class="gmail_quote">
<div>пт, 29 сент. 2017 г. в 17:55, Daniel Baston <<a href="mailto:dbaston@gmail.com" target="">dbaston@gmail.com</a>>:</div>
<blockquote class="gmail_quote" style="margin: 0 0 0 .8ex; border-left: 1px #ccc
solid; padding-left: 1ex;">
<div>This is tangential to this specific proposal, but I am wondering
whether we should establish some general rules for how long to support old
versions of dependencies.
<div> </div>
<div>For example, we could decide to support <dependency n> in new
versions of PostGIS until <timespan> after <dependency n+1> is
released. As an example, we could decide to support GEOS 3.4 in new versions
of PostGIS until 2 years after GEOS 3.5 is released.</div>
<div> </div>
<div>Or alternatively, we could say that we support the latest released version
of <dependency>, plus any versions released within the past
<timespan>. So we could decide to support GEOS 3.6, plus any versions of
GEOS released in the past three years (3.4 dates back to 2013, so this would
limit it to 3.5 and 3.6).</div>
<div> </div>
<div>I'm just throwing these out for the sake of examples, but I think some
guidelines along these lines could help make these decisions simpler and more
predictable for users/packagers.</div>
<div> </div>
<div>Dan</div>
</div>
<div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 29, 2017 at
10:40 AM, Regina Obe <span><<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;">While we are still in infancy of PostGIS 2.5 (and probably
at least a year<br> away from release), I'd like to get requirements out of the
way and propose<br> the following:<br><br> 1) Drop support for PostgreSQL 9.4
and 9.5 (so PostgreSQL 9.6 - PostgreSQL<br> 11 will be supported)<br> 9.4 has
the main annoyance of not supporting true KNN and I'm tired of<br> explaining
this to folks and having people with pg_upgrading from these<br> lowers being
screwed when upgrading because they can no longer do<br><br> ALTER EXTENSION
.. cause they are already at 2.5.0<br><br> 9.5 doesn't support Parallelism
and I suspect we may need to do some<br> restructuring for some aggs in 2.5, I'd
just assume not have to make special<br> concessions for folks trying to
pg_upgrade from a PostgreSQL 9.5 2.5<br> extension to 9.6+<br><br> 2) Make GEOS
3.5+ the minimum (for 2.4 GEOS 3.4 was the minimum) - we've<br> got too much
stuff that requires 3.5 already that is turned off for lower<br> and newer GEOS
has some robustness improvements.<br><br> 3) Make Proj 4.9+ the minimum
currently our minimum is proj 4.7 I think. As<br> discussed it's on the table
to redo some of the geography stuff like<br> ST_Segmentize using proj 4.9+
features.<br><br><br> Anyone have issues with the above?<br><br> PSC folks, if
you are okay with all the above please give a +1<br><br> If you are okay with
some and not others, I can break apart so we can at<br> least decide on some
pieces.<br><br><br> Thanks,<br> Regina<br><br>
_______________________________________________<br> postgis-devel mailing
list<br><a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br><a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a>
</blockquote>
</div>
</div>
_______________________________________________<br> postgis-devel mailing
list<br><a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br><a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a>
</blockquote>
</div>
</div>
<br><hr>
<br> _______________________________________________<br> postgis-devel mailing
list<br> postgis-devel@lists.osgeo.org<br><a href="../hwebmail/services/go.php?url=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fpostgis-devel" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a>
</blockquote>
<p style="margin: 0; padding: 0;"><br><br></p>
<p><br> --<br>Brian M Hamlin<br> OSGeo California<br> blog.light42.com<br></p>
<p style="margin: 0; padding: 0;"> </p>
</body>
</html>