On 9/4/19 12:58 PM, Christoph Berg wrote: > Re: Sebastiaan Couwenberg 2019-09-04 > <e4f157c2-2b6f-0015-5244-c1fed8345...@xs4all.nl> >> Not much we can do about this. PROJ 6 just migrated to testing and we'll >> need to update a lot more of the stack to get them to support it fully. > > Oh, if that's just a transient thing then it's not a big deal at all. > > We just shouldn't release it in that state, it really printed 2 or 3 > screens full of that which would be quite embarrassing to see in > stable.
bullseye will release sometime in 2021, plenty of time to update the rest of the stack to versions with full support for PROJ6. This will include at least GDAL >= 3.x, QGIS >= 3.10.x, PostGIS >= 3.x, GRASS >= 3.8 which all have support PROJ 6. PROJ 7 is scheduled for release in March 2020, and will drop support for proj_api.h which many other projects still use, most importantly spatialite. And it doesn't look like it will see a release that supports the proj.h API (introduced in PROJ 5) before that time. So I don't think we can release bullseye with PROJ 7, but PROJ 6 seems very doable. With the first steps taken to get PROJ 6 into bullseye by transitioning to PROJ 6.2.0 and libgeotiff 1.5.1 we now need to continue with rest of stack. GDAL 3 is ready in experimental, but not all rdeps are ready for it yet (no big blockers though). GRASS 3.8 will publish the final release soon with the major changes including support for PROJ 6 and the switch to Python 3. PostGIS 3.x will take a bit more time until the final release, but should happen sometime next year at the latest I expect. And we'll switch to QGIS 3.10 when it becomes the next LTR in early 2020 as mentioned before. A major change to the stack like PROJ 6 needs quite some time to settle, please be patient while we update the other packages for it. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
