Re: Future maintainance releases
Bas Couwenberg <[email protected]> Wed, 30 Oct 2019 09:56:10 +0100
| Newsgroups | gmane.comp.gis.proj-4.devel |
|---|---|
| Message-ID | <[email protected]> |
On 2019-10-30 09:30, Even Rouault wrote: >> 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... In Debian we're still in the middle of migrating to PROJ 6, we've passed the first step and have PROJ 6.2.0 in unstable and several packages have been updated which include support for proj.h, others have been updated to define ACCEPT_USE_OF_DEPRECATED_PROJ_API_H. GDAL 3 is the next big step, which is currently blocked by the removal of the Python 2 support from the package. The proj.h-adoption-status wiki has been updated as much as possible and provides a reasonably good overview where projects stand. Projects that don't have a release with support for proj.h yet include (but are not limited to): * Cartopy * libosmium * libspatialite * Mapnik * MapServer (should gain that support soon) * QMapShack In Debian there are many reverse dependencies of libspatialite and (old versions of) VTK which will delay the adoption of PROJ 7 or will have to be removed from testing to unblock the transition. The next Debian stable release, bullseye, (in Q3/Q4 2021 probably) will almost certainly ship with PROJ 6.x due to the above. During the development cycle for the subsequent release, bookworm, we'll focus on migrating to PROJ 7 and remove everthing that blocks it. Having to remove support for SpatiaLite if that still won't have a release by that time (which unfortunately seems likely) won't be good for users, but it's a necessary evil to unblock progress. Just like breaking some packages which still require python-gdal is. Kind Regards, Bas _______________________________________________ PROJ mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/proj