Future maintainance releases

Hi,

I'm doing currently fixes/enhancements in the vertical transformation sector. 
Backporting them to 6.2 branch would mostly mean just merging master into 
it..., so I think that for future maintainance releases post 6.2.1 we should 
probably abandon any further activity in 6.2 (apart from website/doc related 
fixes since we generate it from them, or a urgent hotfix if some horrible 
regression was identified), and create a branch from master when we're about 
to release, and call it 6.3. API & behaviour wise, master is currently 
compatible with 6.2. There are a few database structure changes, but I'm not 
aware of users who are dependent on it.

But if any of the 2 following pieces of work happens before, then we'll have 
to consider if we want to create this 6.3 branch before they are merged, 
depending on how close they happen from the next planned release:
- EPSG v10 related work (no funding source identified for now): anticipated 
non trivial implications on the database structure and code
- Ondemand network loading of grids (aka "PROJ grid files CDN" topic [1], 50% 
of funding target reached)

The question PROJ 7 or not (if by PROJ 7 we mean removing proj_api.h) will 
also need to be considered. There are still important dependencies like 
Spatialite who haven't yet released a version without proj_api.h dependency 
(as far as I can see from [2], the 'master' contains the changes to use proj.h 
though)

Even

[1] https://lists.osgeo.org/pipermail/proj/2019-September/008858.html
[2] https://www.gaia-gis.it/fossil/libspatialite/info/b72ce4b2a5c7eb77

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj