<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 22, 2017, at 1:49 PM, Kristian Evers <<a href="mailto:kreve@sdfe.dk" class="">kreve@sdfe.dk</a>> wrote:</div><div class=""><div class="WordSection1" style="page: WordSection1; font-family: HelveticaNeue; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span style="font-family: 'Sans Serif', serif; font-size: 9pt;" class=""> </span><br class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span lang="EN-US" style="font-size: 9pt; font-family: 'Sans Serif', serif;" class="">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?<span class="Apple-converted-space"> </span></span></div></div></div></blockquote><br class=""></div>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. <div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">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). </div></body></html>