[PROJ] Future maintainance releases

[Kristian Evers]

> And what about my proposal to branch master as 6.3 while it still qualifies 
> for being a 6.something ? Is there some contractual obligation somewhere to 
> follow exactly the initial plan with a 6.2.2 rather than a 6.3 :-) ?

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

/Kristian

-----Original Message-----
From: Even Rouault <even.rouault at spatialys.com> 
Sent: 30. oktober 2019 09:31
To: proj at lists.osgeo.org
Cc: Kristian Evers <kreve at sdfe.dk>; Sebastiaan Couwenberg <sebastic at xs4all.nl>
Subject: Re: [PROJ] Future maintainance releases

> The next scheduled release [0] that includes new features is PROJ 7. The
> date is set to March 1st 2020. In the meantime two more maintenance
> releases are planned. The last maintenance release of the 6.2 branch is
> scheduled to coincide with 7.0.0. If the improvements regarding vertical
> transformations make it so that it will be difficult to backport changes so
> be it. I reckon that some changes will still be possible to backport but of
> course as master gets farther and farther apart from the 6.2 branch
> backports will get progressively more difficult to keep up. Such is life.

Basically I tried to tell that the createOperations() logic is so involved 
that subtle changes have often unpredicted consequences, so backporting just a 
"fix" even if that applies cleanly (and that won't anymore since I just 
refactored it in master) can lead to different results, if some previous 
"enhancement" commits haven't been applied too. Mastering the logic in one 
branch is already very challenging. Mastering it in 2 branches is not doable. 
This is my statement that I'm unable in practice to maintain 6.2 anymore 
regarding createOperations() (and most of the backporting activity is related 
to that as far as I can tell)

> We can skip the January 1st release of 6.2.2 if there is not a substantial
> number of bug fixes to the branch.

And what about my proposal to branch master as 6.3 while it still qualifies 
for being a 6.something ? Is there some contractual obligation somewhere to 
follow exactly the initial plan with a 6.2.2 rather than a 6.3 :-) ?

> Even, what other important dependencies are still lagging behind?

No idea, but Bas previous message makes me believe that seing PROJ 7 (without 
proj_api.h) deployed would take even more time than PROJ 6...

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