What changes in on disk format are needed? Can they be solved by making a new type of geometry that will hold new format internally, and keep readers/headers for current format? This way the migration can be seamless and delayed and done even in minor. <br><br><div class="gmail_quote"><div dir="ltr">On пн, 9 ліп 2018, 23:05 Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca">pramsey@cleverelephant.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Well, that’s a big change and I was hoping to hold 3 for a change in the disk format rather than burn it for administrivia… interested to hear what others have to say. +/- 0<br>
P<br>
<br>
> On Jul 9, 2018, at 1:03 PM, Regina Obe <<a href="mailto:lr@pcorp.us" target="_blank">lr@pcorp.us</a>> wrote:<br>
> <br>
> We've been quietly toying with this idea, but would like to put in stone.<br>
> <br>
> Instead of having yet another minor of 2, let's go to 3.0.<br>
> <br>
> Hey we went from 1.5 to 2, seems appropriate to go from 2.5 to 3.<br>
> <br>
> All PostGIS developers and packagers I'd like your feedback too since it<br>
> will sway our decision.<br>
> <br>
> My main reason for wanting to jump to 3.0 is so we can standardize on<br>
> dropping the minor version in our  lib file.<br>
> <br>
> So that means 3.0 would have a lib file<br>
> postgis-3.whatever_extension_os_prefers.<br>
> <br>
> <br>
> No postgis-3.0  etc.  just postgis-3<br>
> <br>
> And thenceforth all PostGIS from 3.0 on will no longer have the .minor<br>
> version and we will promise as a project to ensure we will not remove C-API<br>
> functions referenced in prior 3.whatever  SQL api and never do so during the<br>
> series of a major release.<br>
> Thus making pg_upgrade possible without having install an older version of<br>
> PostGIS or to do hacks symlink  lib files from older versions to newer or<br>
> having people have to ask us - is it okay to symlink?<br>
> <br>
> +1 for 3.0 <br>
> <br>
> Here are some other things on table for 3.0<br>
> <br>
> <a href="https://trac.osgeo.org/postgis/wiki/PostGIS3" rel="noreferrer" target="_blank">https://trac.osgeo.org/postgis/wiki/PostGIS3</a>  (breakout of postgis raster I<br>
> am totally against :) )<br>
> <br>
> don't forget we've got a code sprint coming up this September to discuss<br>
> this and other topics.  Signup so we know how many people to expect.<br>
> <br>
> <a href="https://trac.osgeo.org/postgis/wiki/PostGISCodeSprint2018" rel="noreferrer" target="_blank">https://trac.osgeo.org/postgis/wiki/PostGISCodeSprint2018</a><br>
> <br>
> <br>
> If you are only going to join remotely, it's okay to put your name on their<br>
> but with note (Remote)<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" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><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" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a></blockquote></div>