Hey, I know it has been said before, but changing the GDAL/Proj version of the LTR versions is really a no go. It's a breaking change in terms of possible breakages and just increases risks on a version we need to stay stable.
We are communicating to users they should use the LTR because it's stable but changing the major dependencies under the hood with new versions breaks this trust and message. It would be like changing the Qt version inside an LTR point release, we just can't do it because it's a full major change with massive impacts. The risk of the LTR running on older stacks is seen as a net positive not a negative when it comes to stability for users. The moment we break this trust we lose all the work past work we have put in to communicate this message, trust is hard to gain and easy to lose. I'm not sure what the solution here is because I know OSGeo4w doesn't really support that kind of separation yet but if we have a way to fund this kind of work I would really like us to consider it (unsure the state of the budget but this one is critical IMO). It's going to be an ongoing issue and something that will always have to be resolved with each LTR as it moves away from the nightlies with the dependencies changing. I wish I had the skills and time to help fix this but at the moment all I can offer is my concern. Regards, Nathan On Sat, Nov 23, 2019 at 10:26 PM Tim Sutton <[email protected]> wrote: > Hi > > We also have situations like this [1] where we are breaking the LTR with. > Big bumps in GDAL/PROJ version. > > Could we either a) invest QGIS bug fixing money into resolving these or b) > adopt a more conservative approach to adopting new versions of libraries? > > [1]https://github.com/qgis/QGIS/issues/32953 > > Regards > > Tim > > On 23 Nov 2019, at 11:23, Paolo Cavallini <[email protected]> wrote: > > Hi Tim, > > Il 23/11/19 11:22, Tim Sutton ha scritto: > > > For windows at least we could ‘freeze’ 3.4.x by pointing them to use the > standalone installers but then we have an LTR that is not getting bug > fixes. As I read Jürgen’s roadmap [1] we still have 4 more bug fix > releases of 3.4 before 3.10 becomes LTR, which is quite a long time to > have our ’stable’ version out there with no bug fixes. > > > yes, that's what I meant. It's a kind of bad hack, so as Bas also > pointed out the proper solution is just to go ahead and fix the bugs. > I feel bad about people wasting their time to fix this compatibility bug > that will be useful just for a relatively short period, however. > Cheers. > -- > Paolo Cavallini - www.faunalia.eu > QGIS.ORG Chair: > http://planet.qgis.org/planet/user/28/tag/qgis%20board/ > _______________________________________________ > 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 > > > — > > > > > > > > > *Tim Sutton* > > *Co-founder:* Kartoza > *Ex Project chair:* QGIS.org > > Visit http://kartoza.com to find out about open source: > > Desktop GIS programming services > Geospatial web development > GIS Training > Consulting Services > > *Skype*: timlinux > *IRC:* timlinux on #qgis at freenode.net > > I'd love to connect. Here's my calendar link > <https://calendly.com/timlinux> to make finding time easy. > > _______________________________________________ > 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
