[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