<div dir="auto">+1 for this type of backport</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 25, 2019, 11:15 PM Kristian Evers <<a href="mailto:kreve@sdfe.dk">kreve@sdfe.dk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think we should accept that some changes will be required during the first<br>
few months of PROJ 6. So, I am fine with this change.<br>
<br>
In the future (maybe from 6.1.0?) we should stick to the concepts of semantic<br>
versioning, in the same way we do with code. So, only bug fixes in patch-releases,<br>
which for the database I think should also include data updates. Minor version<br>
releases can add new tables etc, but not remove anything and of course breaking<br>
changes should only be allowed in major version releases.<br>
<br>
/Kristian<br>
<br>
> On 25 Mar 2019, at 17:44, Even Rouault <<a href="mailto:even.rouault@spatialys.com" target="_blank" rel="noreferrer">even.rouault@spatialys.com</a>> wrote:<br>
> <br>
> Hi,<br>
> <br>
> In <a href="https://github.com/OSGeo/proj.4/pull/1368" rel="noreferrer noreferrer" target="_blank">https://github.com/OSGeo/proj.4/pull/1368</a> , I've committed a few changes:<br>
> - update of database with latest content of EPSG, IGNF and ESRI registries<br>
> - add an extra column (operation_version) to tables that store coordinate <br>
> operations. This change was triggered by the fact that very recent evolutions <br>
> of the WKT2:2018 candidate standard have lead to adding this information in <br>
> WKT2, and this wasn't imported into the database until now since there was no <br>
> use in the code base before.<br>
> <br>
> Are there thoughts about if this is material appropriate for backport to <br>
> 6.0.x? (the backport iself is technically trivial)<br>
> <br>
> My point of view is that generally stable branches should be for bugfixes <br>
> only, and not feature changes, and such changes could be considered as <br>
> features.<br>
> <br>
> But as 6.0.0 is really a version with a lot of changes that takes time to be <br>
> adopted, we might perhaps consider that its first bugfix release can receive <br>
> more changes withouth having bad consequences (apart from the database content <br>
> change, the only consequence would be if people use the capability to attach <br>
> extra custom databases to the main one, and in that case those databases must <br>
> have the same table structure as the main one, but I'm not aware of anyone <br>
> having used that)<br>
> <br>
> Even<br>
> <br>
> -- <br>
> Spatialys - Geospatial professional services<br>
> <a href="http://www.spatialys.com" rel="noreferrer noreferrer" target="_blank">http://www.spatialys.com</a><br>
> _______________________________________________<br>
> PROJ mailing list<br>
> <a href="mailto:PROJ@lists.osgeo.org" target="_blank" rel="noreferrer">PROJ@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
<br>
_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank" rel="noreferrer">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
</blockquote></div>