Time for a new release?

classic Classic list List threaded Threaded
45 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Time for a new release?

Even Rouault-2

 

> When thinking about a deprecation/migration path, please keep packaging

> systems and the impacts on depending projects in mind. This was pretty

> painful with geos when there were only a small number of other packages

> using deprecated/changed APIs.

>

> Right now a very large amount of software uses the current/old/stable

> API. The main path to removing that should be:

>

> Publish a release with a new supported API. Include in the release

> notes the intent to deprecate/remove the old one.

>

> Expect upstream software to look for the new API and use it, and if

> not found, use the old API.

>

> 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"

 

>

> Find all the projects that use proj and help/prod them into updating

>

> Eventually, decide that projects that have not both changed their code

> to use the new API and *had a formal release with the changes* are

> unmaintained and that packaging systems *should* drop them.

>

> Make a new proj release without the old API. Understand that

> packaging system maintainers are now faced with a choice to hold off

> on updating proj or to remove other packages that haven't updated.

 

Agreed. That was what I underlined in a previous message. There is a need for an interim proj version that have both old and new API, so that software using proj can be progressively updated to use the new API when they have a new release. One year seems to be the minimum reasonable for such transition.

 

>

> An alternate path is:

>

> Construct a new proj release that has a *completely disjoint set* of

> installed files, so that it's reasonable to have proj 4 and proj 5

> installed.

 

That will not help for complex systems. Take QGIS. QGIS uses proj directly, and links against GDAL which also uses proj, and libspatialite with also uses proj. So QGIS, GDAL and libspatialite need to use the same proj version, or symbol clashing will occur. That would work only if "libproj4" and "libproj5" export a completely set of symbols, in addition to files.

 

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Time for a new release?

Kristian Evers-2
In reply to this post by Greg Troxel-2
I don’t care all that much which way we go, as long as there’s a clear decision. If we want to introduce breaking changes, I want to know it as soon as possible so I can get to work before we freeze the code. If we are going along the path of backwards compatibility there’s other stuff I want to focus on.

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.

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?

Kristian


> On 17 Nov 2017, at 19:15, Greg Troxel <[hidden email]> wrote:
>
>
> Kristian Evers <[hidden email]> writes:
>
>> PROJ v. 5.0.0 is also good with me. It also brings us into "braking
>> changes territory". With this in mind I think we should consider only
>> supporting the new API in proj.h and dropping the other APIs. This
>> will allow us to simplify the code immensely. At the moment we jump
>> through a bunch of hoops to keep backwards compatibility. We'd
>> probably still do that for the next release, but not having projects.h
>> and proj_api.h as part of the public API we can change things behind
>> the scenes in future releases.
>
> When thinking about a deprecation/migration path, please keep packaging
> systems and the impacts on depending projects in mind.  This was pretty
> painful with geos when there were only a small number of other packages
> using deprecated/changed APIs.
>
> Right now a very large amount of software uses the current/old/stable
> API.  The main path to removing that should be:
>
>  Publish a release with a new supported API.  Include in the release
>  notes the intent to deprecate/remove the old one.
>
>  Expect upstream software to look for the new API and use it, and if
>  not found, use the old API.
>
>  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.
>
>  Find all the projects that use proj and help/prod them into updating
>
>  Eventually, decide that projects that have not both changed their code
>  to use the new API and *had a formal release with the changes* are
>  unmaintained and that packaging systems *should* drop them.
>
>  Make a new proj release without the old API.   Understand that
>  packaging system maintainers are now faced with a choice to hold off
>  on updating proj or to remove other packages that haven't updated.
>
> An alternate path is:
>
>  Construct a new proj release that has a *completely disjoint set* of
>  installed files, so that it's reasonable to have  proj 4 and proj 5
>  installed.
>
>  Do not have any compat in proj 5, and expect programs to migrate to it
>  over time.
>
>  Continue to have security updates, if warranted, for the old package.
>
>
> I'm not sure what people are thinking, but I tend to hear things like
> "people who haven't updated their code can just use the old version".
> The problem is that packaging systems have to make choices, and almost
> all software gets run via packaging systems.  And, as soon as some
> programs move to requiring the new API only, it's not possible to run
> everything on the same system if the current release of proj drops the
> old API.
>

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Time for a new release?

Sebastiaan Couwenberg
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.

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.

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.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Time for a new release?

Greg Troxel-2

Sebastiaan Couwenberg <[hidden email]> 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.



_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

signature.asc (167 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Time for a new release?

Greg Troxel-2
In reply to this post by Even Rouault-2

Even Rouault <[hidden email]> 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.


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

signature.asc (167 bytes) Download Attachment
123