[Proj] Coming releases of PROJ.4

[Howard Butler]

> On Jun 22, 2017, at 1:49 PM, Kristian Evers <kreve at sdfe.dk> wrote:
>  
> So to sum up, for the next release we will keep projects.h, proj_api.h and proj.h as public interfaces to PROJ.4. We will make sure that proj.h is a proper alternative to proj_api.h, and keep both in a maintenance version for a longer period, e.g. two years. After the 4.9.4 release we will start working on getting rid of (publicly available) projects.h, proj_api.h, autotools and nmake in version 10.0.0 and backport bug fixes and new proj.h functionality to 4.9-maintenance. Agreed? 

Ditching manually-constructed and out-of-date nmake for cmake seems fine to me (ooh, CMake gives me project files now!), but ditching autotools that has worked for people for decades does not. That change would ripple into packagers and the distros for little or no appreciable benefit. 

I'm generally enthusiastic in spirit about the rest of your proposal, but I must say I'm very skeptical that we can actually *remove* anything -- especially headers with ambiguous public vs. private behavior that people now depend upon. We can add a new one, and we can make make a much cleaner and less ambiguous API, but I don't think we can take the old ones back. There's just too much momentum and calcification that is going to make it near impossible to go back and update external code to work with a new arrangement of such a foundational library such as Proj.4. I think we are stuck with the (API) sins of our forefathers, but I'd like to hear from more people who think we are not. 

We need to be delicate about changing things for a library such as Proj.4 only for the sake of being "better". This is an unfortunate consequence of maintaining a library that everything ultimately uses (and started using 20+ years ago). 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20170622/8fae788f/attachment.html>