[Proj] Coming releases of PROJ.4

[Kristian Evers]

> I think that it is important to have at some point a release that has both functional proj_api.h and proj.h so that it can serve as a migration basis

I might not have expressed myself clear enough in the initial write-up. The next release, 4.9.4, will include both proj_api.h and proj.h. We should put in the effort to bring proj.h in a state where it can replace proj_api.h. I am able to spend a fair amount of time on this during the next month or so.

> I'm also thinking to Linux distributions that will be able to ship only a single proj version and will perhaps have packages that still use the old API while others have already migrated.

Good point.


> I'm thinking as a potential test for the new API to use the code sprint at FOSS4G-Europe to try to make GDAL use the new API.

That would be awesome!


>  Yes, proj.h should be as clean as possible. And I wouldn't mind if there are duplicated declarations in proj.h and proj_api.h. Actually I think both should be mutually exclusive and self-contained. It makes little sense to include both in the same compilation unit. Of course that will require some care of not putting conflicting declarations for the same function...


I agree. I think today, from the users perspective, proj.h and proj_api.h are mutually exclusive already. But yeah, the cut should be cleaner.

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?

Kristian

Fra: Even Rouault [mailto:even.rouault at spatialys.com]
Sendt: 22. juni 2017 20:23
Til: Kristian Evers
Cc: proj at lists.maptools.org
Emne: Re: SV: [Proj] Coming releases of PROJ.4




> It was also why I suggested to keep a maintenance version based on 4.9.4 for

> a few years. So developers have time to absorb the changes in their own

> time.



I think that it is important to have at some point a release that has both functional proj_api.h and proj.h so that it can serve as a migration basis. If a project doesn't want to be compatible of both API and migrate directly to the new API, it must be able to rely on the new API in a release. So maintainance versions of 4.9 will have to fix potential issues in proj.h and related implementation. I'm also thinking to Linux distributions that will be able to ship only a single proj version and will perhaps have packages that still use the old API while others have already migrated.



I'm thinking as a potential test for the new API to use the code sprint at FOSS4G-Europe to try to make GDAL use the new API.



> I think it should be possible to remove the dependency of proj_api.h in

> proj.h. Perhaps by putting the parts that are dependant on proj_api.h in a

> proj_internal.h as suggested in your GitHub issue?



Yes, proj.h should be as clean as possible. And I wouldn't mind if there are duplicated declarations in proj.h and proj_api.h. Actually I think both should be mutually exclusive and self-contained. It makes little sense to include both in the same compilation unit. Of course that will require some care of not putting conflicting declarations for the same function...





--

Spatialys - Geospatial professional services

http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20170622/f48ab7d8/attachment.html>