[PROJ] Release schedule between version 6.0.0 and 7.0.0
Kristian Evers
kreve at sdfe.dk
Tue Mar 5 06:29:57 PST 2019
The removal of the old APIs is certainly going to create some friction.
As Bas has stated many times there exist old packages that are unlikely
to be updated to use PROJ 6+. I am of the opinion that if a package is
that unmaintained it probably shouldn't be included in a package system.
That is of course easy for me to say, as I don't have to deal with all the
consequences of removing those package. It is important that we as a
community find a good solution to deal with this.
One solution to this transition phase we are in at the moment is for
packagers to maintain two PROJ packages: proj4 and proj. With proj4
being legacy PROJ (version <=5.2.0) and proj being an up to date version
(>=6.0.0). The proj4 package should probably only install shared libraries
and not command line utilities. I am aware that this approach will not be
suitable for everyone but it may be a good option for some.
It would be nice to have an overview of projects that depend on PROJ
and their proj.h adoption status. Bas made a list about a year ago of
the relevant packages in Debian. That is a good starting point, for anyone
who wants to maintain a list like this.
/Kristian
-----Oprindelig meddelelse-----
Fra: Greg Troxel <gdt at lexort.com>
Sendt: 5. marts 2019 15:12
Til: Kristian Evers <kreve at sdfe.dk>
Cc: proj at lists.osgeo.org
Emne: Re: [PROJ] Release schedule between version 6.0.0 and 7.0.0
[prematurely sent the previous]
Thanks - that all sounds good.
Certainly thinking about it later seems wise, but it's going to be
interesting to see how the transition to 6 in packaging systems goes.
While one can think about users making individual choices based on what
depending programs they want, and perhaps mulitple versions in different
prefixes or packaging approaches that basically use a prefix per package
(to avoid this issue), I think most people are going to be using what
their systems provide and thus either complaining that proj is old or
that foo is not available.
I wonder if it makes sense for proj to track the set of depending
projects that don't work with 6, with links to the tickets in those
projects' trackers. That may be a step too far.
FWIW, postgis seems likely to have a 2.5.2 that works with proj 6 soon.
(2.5.1, the current release, does not.)
More information about the PROJ
mailing list