[Proj] Coming releases of PROJ.4
Kristian Evers
kreve at sdfe.dk
Thu Jun 22 10:13:09 EST 2017
All,
Lately I have been thinking about the future of PROJ.4. FOSS4G is coming up soon,
and for the last couple of years a new version of PROJ.4 has been released at the same time. I
think we should follow that tradition this year, but also mix it up a bit after that. Below is a rough
plan of how I would like to see PROJ.4 evolve over the next 2-3 years.
The executive summary is:
1. Release three times a year
2. Introducing major breaking changes after the next release that
a. Only has one public API
b. Only has one build system
3. ... while keeping a maintenance version alive for two years
4. Restructure version numbering (4.9.x -> 10.0.0)
And now the gory details.
At the moment PROJ.4 has three different public API's: projects.h, proj_api.h and proj.h. The
main driver for adding new API's has been to add a new dimension. With proj_api.h came the
vertical component and with proj.h time has been introduced to PROJ.4 as well. So in a sense
they mark the changing of eras of the needs of the geospatial community with regards to
coordinate transformation. Albeit most have yet to realize the importance of the time component,
it is clear that it will play an important role in the not so far future.
I propose that we narrow that down to just one API and one build system over the coming
years. The projects.h interface has a long history and exposes most of the inner workings
of PROJ.4. Originally it was simple but during the years it has become quite complicated. I don't
think it is particularly suitable as the public interface for this library. That is also why the
proj_api.h interface exists. It was created in an effort of simplifying things and making a
more modern API. That was now roughly 15 years ago, and it is perhaps not so modern
anymore. On top of that it has some unfortunate design choices, for instance the
context-system which is rather hard to work with and comprehend. Unfortunately it is also
completely undocumented and the original ideas behind it seem to be lost.
PROJ.4 also has three different build-systems: Autotools, nmake and CMake. Autotools is the
authoritative build-system which the other two try to mimic as best as possible. Nmake was
introduced in order to build PROJ.4 on Windows and lately CMake has also been introduced
as there was a demand for it.
Due to the above I suggest that we focus our efforts entirely on the proj.h API and CMake
from the next release and onwards. For that to be a proper success we will have to abandon
the older API's and build systems. Of course that is not something that can be done from one
day to the next. Hence I think we should phase them out over a long period of time.
My idea is to start working on simplifying PROJ.4 immediately after the next release, with the
aim of being able to release a fully working and simplified library in august 2018. In parallel
we should maintain a backwards compatible version for two years, to give developers amble
time to adjust to the many changes that will be introduced. I envision that new projections
and possibly other changes are applied to the maintenance version for the first years, and
after that only critical bug fixes will be applied. This should ensure that people can use the
library without problems until they make the transition to the new simplified version.
This is also a good time to restructure the version numbers. Today we have a system where
The major release number is fixed (or at least would be quite controversial to change), leaving
just to numbers to change at release. Ideally we should follow the structure of Semantic
Versioning [0]. I propose that the next release that breaks the API is called "PROJ.4 10.0.0".
This way we get around the awkward situation we have today, signal to the world that
something substantial has happened and we have a better version numbering system going
forward.
Below is a detailed plan of how my proposed release schedule for the next three years:
Version Time of release Action
------- --------------- ----------------------------------------------------------
4.9.4 August 2017 - "Standard" release of current master branch.
- Announce that this will be the final version where
projects.h is publicly accessible.
- Introduce proj.h as the "API of the future".
tag as experimental.
- Create branch 4.9-Maintenance.
4.9.5 December 2017 - Backport new projections.
- Bug Fixes.
4.9.6 April 2018 - Backport new projections.
- Bug Fixes.
4.9.8 August 2018 - Backport new projections.
- Bug Fixes.
- Last version of 4.9.x that introduces new features.
In maintenance mode from now on.
10.0.0 August 2018 - First version without projects.h and proj_api.h
- Only use CMake as build-system.
- proj.h no longer experimental.
- Create branch Release-10.0
4.9.10 December 2018 - Maintenance release. Only bug fixes.
10.x.y December 2018 - Regular release. New features. Bug fixes.
4.9.11 April 2019 - Maintenance release. Only bug fixes.
10.x.y April 2019 - Regular release. New features. Bug fixes.
4.9.12 August 2019 - Final release. Only bug fixes.
- The 4.9-branch will be discontinued.
10.x.y August 2019 - Regular release. New features. Bug fixes.
10.x.y December 2019 - Regular release. New features. Bug fixes.
10.x.y April 2020 - Regular release. New features. Bug fixes.
10.x.y August 2020 - Regular release. New features. Bug fixes.
This is a lot at once, but I think it is necessary to make the library easier to maintain in
the future. Please let me know what you think about this. If the description isn't detailed
enough I am happy to elaborate my thoughts.
/Kristian
[0] http://semver.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20170622/8f8516df/attachment-0001.htm
More information about the Proj
mailing list