[Proj] Time for a new release?

[Greg Troxel]

Even Rouault <even.rouault at spatialys.com> writes:

>>   Perhaps have a release with a define that has to be on to use the
>>   old API.  But this doesn't really do what you think, because people
>>   maintaining packaging systems will notice the failure to build and
>>   turn on the define.
>
> The advantage of that #define is that I'd expect packagers to file
> bugs/email to upstream projects in case they are not aware of the
> upcoming breakage. "Heh project X, at the next proj upgrade, your
> software will not build against it. Please make sure to have a release
> soon using the new API, otherwise it will get removed"

Perhaps, but I think this is putting packagers in the middle of an issue
between proj and proj-using packages, and it doesn't really help.

Perhaps the proj crowd can file bugs with all known proj-using packages,
as soon as a proj release with the new API exists, and have a
corresponding tracking bug in the proj tracker, so we can see how things
are going.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 162 bytes
Desc: not available
Url : http://lists.maptools.org/pipermail/proj/attachments/20171117/67bef44c/attachment.pgp