[Proj] Time for a new release?

[Kristian Evers]

PROJ v. 5.0.0 is also good with me. It also brings us into "braking changes territory". 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'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.


Kristian

-----Oprindelig meddelelse-----
Fra: proj-bounces at lists.maptools.org [mailto:proj-bounces at lists.maptools.org] På vegne af Greg Troxel
Sendt: 10. november 2017 22:24
Til: Howard Butler <howard at hobu.co>
Cc: PROJ.4 and general Projections Discussions <proj at lists.maptools.org>
Emne: Re: [Proj] Time for a new release?


Howard Butler <howard at hobu.co> writes:

> On Fri, Nov 10, 2017 at 12:53 PM, Norman Vine <nhv at meganet.net> wrote:
>
>>> Yes, this upcoming release is a good occasion to de-emphasize the "4".
>>>
>>> > Having the next release be PROJ v.5.0.0 is fine with me.
>>>
>>> Yes, like this the name will be separated from the version number and future-ready.
>>
>> +1
>
> This is enough consensus to satisfy me.
>
> PROJ v5.0.0 it is!

Sounds good to me to.

FWIW, the current pkgsrc package is:

  proj-4.9.3

and it installs:

  /usr/pkg/include/org_proj4_PJ.h
  /usr/pkg/include/org_proj4_Projections.h
  /usr/pkg/include/proj_api.h
  /usr/pkg/include/projects.h
  /usr/pkg/lib/libproj.la
  /usr/pkg/lib/libproj.a
  /usr/pkg/lib/libproj.so
  /usr/pkg/lib/libproj.so.12
  /usr/pkg/lib/libproj.so.12.0.0
  /usr/pkg/lib/pkgconfig/proj.pc

so the big thing remaining is whether the include paths that  have 4 in
them are staying, or if all the code that uses it are going to have to
search for two pathnames and have HAVE_ ifdefs  from
autoconf/cmake/whatever.