Decision: Make projects.h a private header after the next release?

[kbevers]

I suggested on the mailing list that the projects.h header be made private after the next release. There was much debate, but no real conclusion. We need to make a decision before the next release, so that a potential removal of projects.h from the public API can be announced in the release notes.

There are two options:

1. Leave it as is
2. Make projects.h private

The discussion on the mailing list revealed that there are still a handful or two projects that rely on functions in projects.h. Various package maintainers recommended that nothing be changed. I, and a few others, on the other hand are in favour of removing projects.h from the public interface since it will enable us to change more things internally in PROJ.4. Additionally projects.h has been marked for internal use only for many years and it was even removed between version 4.8 and 4.9. I think it is fair to say that users of projects.h has been warned long enough already.
With the introduction of the new API in the next release we have the opportunity to bridge the gap between the functionality in projects.h and proj_api.h and create an API that is superior to both. We are already well on the way. Migration should be fairly simple in most cases.

@hobu, in the end this is your decision I think (hence the ticket assignment). Others should of course feel free to chime in with their opion.

[busstoptaktik]

+1

[pl-nfwarmerdam]

I do not have any strong objection, but it will end up causing some pain to a few downstream projects. I would encourage loudly declaring this change in the release notes.

[kbevers]

The decision has been made to remove projects.h with version 6.0.0. Has been announced in the release notes attached to PROJ 5.0.0RC1 that was just released.