[Proj] Time for a new release?

[Even Rouault]

On samedi 11 novembre 2017 17:32:05 CET Kristian Evers wrote:
> 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. 

Can you sketch a bit what would be simplified in doing so ?

> 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.

If I remember the analysis of Debian packages, while dropping projects.h would have a 
moderate impact, dropping proj_api.h would cause massive breakage. This would likely cause 
proj 5 to take months to years before being available in distributions due to many packages 
not being ready for it (and the proj_api.h -> proj.h port is the kind of change that needs to be 
done by upstream projects. not a quick&dirty hack that the packager can do)
Thus in this context of software distributions, applications that would be adapted to use the 
new API wouldn't be able to use it in practice for a long time. Worse, applications that would 
do the changes to support proj >= 5 would still to have to support both proj < 5 and proj >= 5 
in a transition period if they want their new releases to be packaged. To make their life easier 
by avoiding to have them to support both API, a proj 5 should be available as packaged as 
fast as possible.

I'm wondering if there wouldn't be a way of having a proj_api.c compatibiliy layer that would 
use the new API  behind the scene ? The projPJ struct could be something different than the 
PJ one, for example just storing the text. And when doing pj_transform() you would build a 
pipeline from the src and dest projPJ. Things like that. I believe the cost of creating this 
compatibility layer (assuming this is possible) would be worth it


Or alternate plan :

- for proj 5.0, add at top of proj_api.h

#ifndef I_AM_M_AWARE_PROJ_API_H_WILL_BE_REMOVED_IN_PROJ_5_1
#error "proj_api.h will be removed in proj 5.1. You can still use it for now by defining 
I_AM_AWARE_PROJ_API_H_WILL_BE_REMOVED_IN_PROJ_5_1, but you should strongly 
consider using proj.h now"
#endif

Perhaps do the same for projects.h, if we really want proj 5 to be a no-brainer for packagers

- for proj 5.1, remove proj_api.h (and projects.h)


Benefits:
* this would make proj 5 easy to be packaged, by avoiding a flag day
* applications would be clearly warned they have to do something, and have time to do the 
changes
* after proj 5.0 release, proj master could benefit from the needed cleanups.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20171111/d166e23b/attachment-0001.htm