[Proj] Time for a new release?
gdt at lexort.com
Fri Nov 17 18:23:14 EST 2017
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 162 bytes
Desc: not available
Url : http://lists.maptools.org/pipermail/proj/attachments/20171117/67bef44c/attachment.pgp
More information about the Proj