[PROJ] Backport policy to 6.0.x for database content and structure change ?

[Kurt Schwehr]

+1 for this type of backport

On Mon, Mar 25, 2019, 11:15 PM Kristian Evers <kreve at sdfe.dk> wrote:

> I think we should accept that some changes will be required during the
> first
> few months of PROJ 6. So, I am fine with this change.
>
> In the future (maybe from 6.1.0?) we should stick to the concepts of
> semantic
> versioning, in the same way we do with code. So, only bug fixes in
> patch-releases,
> which for the database I think should also include data updates. Minor
> version
> releases can add new tables etc, but not remove anything and of course
> breaking
> changes should only be allowed in major version releases.
>
> /Kristian
>
> > On 25 Mar 2019, at 17:44, Even Rouault <even.rouault at spatialys.com>
> wrote:
> >
> > 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
> > _______________________________________________
> > PROJ mailing list
> > PROJ at lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/proj
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20190326/8ccfd661/attachment-0001.html>