[Proj] Time for a new release?

[Even Rouault]

> When thinking about a deprecation/migration path, please keep packaging
> systems and the impacts on depending projects in mind.  This was pretty
> painful with geos when there were only a small number of other packages
> using deprecated/changed APIs.
> 
> Right now a very large amount of software uses the current/old/stable
> API.  The main path to removing that should be:
> 
>   Publish a release with a new supported API.  Include in the release
>   notes the intent to deprecate/remove the old one.
> 
>   Expect upstream software to look for the new API and use it, and if
>   not found, use the old API.
> 
>   Perhaps have a release with a define that has to be on to use the old
>   API.  But this doesn't really do what you think, because people
>   maintaining packaging systems will notice the failure to build and
>   turn on the define.

The advantage of that #define is that I'd expect packagers to file bugs/email to upstream 
projects in case they are not aware of the upcoming breakage. "Heh project X, at the next 
proj upgrade, your software will not build against it. Please make sure to have a release soon 
using the new API, otherwise it will get removed"

> 
>   Find all the projects that use proj and help/prod them into updating
> 
>   Eventually, decide that projects that have not both changed their code
>   to use the new API and *had a formal release with the changes* are
>   unmaintained and that packaging systems *should* drop them.
> 
>   Make a new proj release without the old API.   Understand that
>   packaging system maintainers are now faced with a choice to hold off
>   on updating proj or to remove other packages that haven't updated.

Agreed. That was what I underlined in a previous message. There is a need for an interim proj 
version that have both old and new API, so that software using proj can be progressively 
updated to use the new API when they have a new release. One year seems to be the 
minimum reasonable for such transition.

> 
> An alternate path is:
> 
>   Construct a new proj release that has a *completely disjoint set* of
>   installed files, so that it's reasonable to have  proj 4 and proj 5
>   installed.

That will not help for complex systems. Take QGIS. QGIS uses proj directly, and links against 
GDAL which also uses proj, and libspatialite with also uses proj. So QGIS, GDAL and 
libspatialite need to use the same proj version, or symbol clashing will occur. That would 
work only if "libproj4" and "libproj5" export a completely set of symbols, in addition to files.


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20171117/e4064638/attachment.html>