[Proj] Time for a new release?

[Greg Troxel]

Sebastiaan Couwenberg <sebastic at xs4all.nl> writes:

> On 11/17/2017 07:39 PM, Kristian Evers wrote:
>> Unfortunately we don’t hear from that many users of the
>> library. Plenty of package maintainers are chiming in, but not many
>> whose code will be impacted by breaking changes. It would be nice to
>> hear get som input from that side of the table.
>
> Not many users of the proj library are subscribed to this list.
>
>> I understand the problem you have as a package maintainer. It is not
>> easy and either way we go is going to be problematic, although
>> keeping backward compatibility seems to be lesser evil. How long do
>> you suggest support for both API’s should last? 1 year? 2 years?
>> Longer?
>
> Ideally longer, especially since this project only sees about one
> release per year.

I agree.  I would say:

  after the release of a proj with the new API, how long will it take
  for 95% of the packages that depend on proj to have a formal release
  that uses the new API?

I think 1 year is wildly optimistic.

> Of the ~50 Debian packages that use proj, many of these projects will
> take quite a while to adapt to the new API, several of which will
> require these changes to be contributed because they won't develop it
> themselves.

agreed

> Helping projects adapt to the new API may be a good subject for sprint
> where interested developers create patches for the various projects that
> lack the resources to adapt to the new API themselves.

That's a great idea.   But then you still need to wait/prod for an
actual release.

Realistically, I think after the new API is in a release, we just have
to wait until we are comfortable discarding all software that hasn't
coped yet.  It's really hard to know how long that will be.


-------------- 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/20171117/8a74ff8f/attachment.sig>