<div dir="auto">Sorry if I am not seeing something that exists.  Is there a document that explains how to transition from the old APIs to the new?</div><div class="gmail_extra"><br><div class="gmail_quote">On Nov 11, 2017 9:34 AM, &quot;Kristian Evers&quot; &lt;<a href="mailto:kreve@sdfe.dk">kreve@sdfe.dk</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">PROJ v. 5.0.0 is also good with me. It also brings us into &quot;braking changes territory&quot;. With this in mind I think we should consider only supporting the new API in proj.h and dropping the other APIs. This will allow us to simplify the code immensely. At the moment we jump through a bunch of hoops to keep backwards compatibility. We&#39;d probably still do that for the next release, but not having projects.h and proj_api.h as part of the public API we can change things behind the scenes in future releases.<br>
<br>
<br>
Kristian<br>
<br>
-----Oprindelig meddelelse-----<br>
Fra: <a href="mailto:proj-bounces@lists.maptools.org">proj-bounces@lists.maptools.<wbr>org</a> [mailto:<a href="mailto:proj-bounces@lists.maptools.org">proj-bounces@lists.<wbr>maptools.org</a>] På vegne af Greg Troxel<br>
Sendt: 10. november 2017 22:24<br>
Til: Howard Butler &lt;<a href="mailto:howard@hobu.co">howard@hobu.co</a>&gt;<br>
Cc: PROJ.4 and general Projections Discussions &lt;<a href="mailto:proj@lists.maptools.org">proj@lists.maptools.org</a>&gt;<br>
Emne: Re: [Proj] Time for a new release?<br>
<br>
<br>
Howard Butler &lt;<a href="mailto:howard@hobu.co">howard@hobu.co</a>&gt; writes:<br>
<br>
&gt; On Fri, Nov 10, 2017 at 12:53 PM, Norman Vine &lt;<a href="mailto:nhv@meganet.net">nhv@meganet.net</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt;&gt; Yes, this upcoming release is a good occasion to de-emphasize the &quot;4&quot;.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; &gt; Having the next release be PROJ v.5.0.0 is fine with me.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Yes, like this the name will be separated from the version number and future-ready.<br>
&gt;&gt;<br>
&gt;&gt; +1<br>
&gt;<br>
&gt; This is enough consensus to satisfy me.<br>
&gt;<br>
&gt; PROJ v5.0.0 it is!<br>
<br>
Sounds good to me to.<br>
<br>
FWIW, the current pkgsrc package is:<br>
<br>
  proj-4.9.3<br>
<br>
and it installs:<br>
<br>
  /usr/pkg/include/org_proj4_PJ.<wbr>h<br>
  /usr/pkg/include/org_proj4_<wbr>Projections.h<br>
  /usr/pkg/include/proj_api.h<br>
  /usr/pkg/include/projects.h<br>
  /usr/pkg/lib/<a href="http://libproj.la" rel="noreferrer" target="_blank">libproj.la</a><br>
  /usr/pkg/lib/libproj.a<br>
  /usr/pkg/lib/libproj.so<br>
  /usr/pkg/lib/libproj.so.12<br>
  /usr/pkg/lib/libproj.so.12.0.0<br>
  /usr/pkg/lib/pkgconfig/proj.pc<br>
<br>
so the big thing remaining is whether the include paths that  have 4 in<br>
them are staying, or if all the code that uses it are going to have to<br>
search for two pathnames and have HAVE_ ifdefs  from<br>
autoconf/cmake/whatever.<br>
______________________________<wbr>_________________<br>
Proj mailing list<br>
<a href="mailto:Proj@lists.maptools.org">Proj@lists.maptools.org</a><br>
<a href="http://lists.maptools.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">http://lists.maptools.org/<wbr>mailman/listinfo/proj</a><br>
</blockquote></div></div>