Yeah don't change anything like this in a LTR. It's not a good idea for trust.
On Tue, 25 Apr 2017, 5:24 PM Matthias Kuhn <[email protected]> wrote: > > Please don't. Embedded code copies are a PITA. QGIS has too many of > those already (although they're generally not required). > > I agree in general. I think this case here is a bit different, given > that this is already partially present (in a particularly cumbersome and > incomplete way) and is going to be phased out soon. > > >>> 5) require GDAL < 2.2 for building QGIS 2.18 > > What about > > > > 6) #ifdef the offending plugin out in 2.18 for GDAL >= 2.2? > > If that's going to be done I would update that to error out in CMake > with an incompatiblity error and force the packager to make a decision > (actively disable dxf2shp or pin GDAL to the older version). > > Which decision would you propose for the packages provided upstream > (like OSGeo4W)? > > > > > Given that the plugin is removed in QGIS 3.0 anyway, I think early > > retirement is a perfectly valid option. It's also the best option for > > GDAL, and avoids any wasted effort temporarily fixing code which only > > has a short time left to live anyway... > > I was thinking the same, but breaking peoples workflows in patch > releases is a good way to undermine the trust in LTR. > > Matthias > > _______________________________________________ > Qgis-developer mailing list > [email protected] > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________ Qgis-developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
