[PROJ] Backport policy to 6.0.x for database content and structure change ?
Even Rouault
even.rouault at spatialys.com
Mon Mar 25 09:44:45 PDT 2019
Hi,
In https://github.com/OSGeo/proj.4/pull/1368 , I've committed a few changes:
- update of database with latest content of EPSG, IGNF and ESRI registries
- add an extra column (operation_version) to tables that store coordinate
operations. This change was triggered by the fact that very recent evolutions
of the WKT2:2018 candidate standard have lead to adding this information in
WKT2, and this wasn't imported into the database until now since there was no
use in the code base before.
Are there thoughts about if this is material appropriate for backport to
6.0.x? (the backport iself is technically trivial)
My point of view is that generally stable branches should be for bugfixes
only, and not feature changes, and such changes could be considered as
features.
But as 6.0.0 is really a version with a lot of changes that takes time to be
adopted, we might perhaps consider that its first bugfix release can receive
more changes withouth having bad consequences (apart from the database content
change, the only consequence would be if people use the capability to attach
extra custom databases to the main one, and in that case those databases must
have the same table structure as the main one, but I'm not aware of anyone
having used that)
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
More information about the PROJ
mailing list