[Proj] Time for a new release?

[Greg Troxel]

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.

-------------- 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/44842d7a/attachment.pgp