[Proj] Time for a new release?

[Kristian Evers]

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 <gdt at lexort.com> wrote:
> 
> 
> Kristian Evers <kreve at sdfe.dk> 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.
>