[PROJ] Future maintainance releases

Kristian Evers kreve at sdfe.dk
Wed Oct 30 12:24:38 PDT 2019



> On 30 Oct 2019, at 12:12, Even Rouault <even.rouault at spatialys.com> wrote:
> 
>> No, not at all. My concern is, or was, that a 6.3 version would be rather
>> short-lived with a release of 7.0 only a few months later.
> 
> Depending on how much time it might take for 7.0 to be deployed to users using 
> binary distribution channels, we might have to maintain a 6.x for some time.

That is certainly a possibility. But it is inevitable that the 6.x branch is going to
go out of date no matter what. I don’t expect that we will be able to keep the
EPSG database up to date for very long in 6.x for instance.

> 
>> But if the
>> changes you are proposing really are so disrupting I agree that it will be
>> beneficial with a new minor-version release. I have one question though.
>> Would it be a benefit to your work on vertical transforms if you were not
>> restricted by the old API? The grid code is somewhat entangled as far as I
>> remember and wouldn't be surprised if some of olde API functions is in the
>> way of the smartest way to do things. If that is the case then I think we
>> should just go straight to 7.0. If you can accomplish your work without
>> working around the existing API a 6.3 release is fine with me.
> 
> For now, I'm most dealing with metadata related work, nothing in the grid 
> handling itself. If the CDN related work happens to be done, yes it will be 
> internally disruptive, but looking quickly at proj_api.h, I'm not even sure 
> the old API would be a problem for that. The only thing that is grid related 
> is pj_apply_gridshift(), but I don't think that would be an issue, and looking 
> in Debian archive for
> https://codesearch.debian.net/search?q=pj_apply_gridshift 
> I can only find mentions of it in PROJ itself or its embedded copies by other 
> projects, so basically no one in the open world is using it.
> 

Right, in that case I think your proposal of introducing 6.3 in the next release
cycle is the best thing to do. I will update the release schedule as follows:

6.3.0		January 1st 2020
7.0.0 + 6.3.1	March 1st 2020

From 7.0 and onwards I think I would like to move to issuing releases every
three months as opposed to the bi-monthly cycle I’ve been keeping the last
two years. It’s less of a burden on me preparing the releases and I expect the
speed of development to slow down a bit now that the most significant chunks
of database work is finalised.

/Kristian


> -- 
> Spatialys - Geospatial professional services
> http://www.spatialys.com



More information about the PROJ mailing list