Re: 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
_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj