[Proj] Coming releases of PROJ.4

[Greg Troxel]

Howard Butler <howard at hobu.co> writes:

> Ditching manually-constructed and out-of-date nmake for cmake seems
> fine to me (ooh, CMake gives me project files now!), but ditching
> autotools that has worked for people for decades does not. That change
> would ripple into packagers and the distros for little or no
> appreciable benefit.

Agreed and well said.

> I'm generally enthusiastic in spirit about the rest of your proposal,
> but I must say I'm very skeptical that we can actually *remove*
> anything -- especially headers with ambiguous public vs. private
> behavior that people now depend upon. We can add a new one, and we can
> make make a much cleaner and less ambiguous API, but I don't think we
> can take the old ones back. There's just too much momentum and
> calcification that is going to make it near impossible to go back and
> update external code to work with a new arrangement of such a
> foundational library such as Proj.4. I think we are stuck with the
> (API) sins of our forefathers, but I'd like to hear from more people
> who think we are not.

Also agreed.

Note that stuck comes in multiple flavors.  If the new API is clean and
sufficient, then any program using the old ones can be urged to upgrade.
Eventually, the old one can go away, but people should be thinking in
terms of multiple years for all depending projects to adjust and have
releases and have those be packaged in every packaging system.

Part of the point of deprecating the old API is getting to remove the
code, but from an abstraction violation POV, a lot of the benefit comes
as each dependency stops using it.


Finally, if there is a big new API, that calls for a version number that
makes this obvious.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 162 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20170623/bd641136/attachment.sig>