> And at this stage in the life of the LTR I just > don't see the risks of regressions outweighing anything but > crash/corruption fixes.
"Stage" is the keyword here. Number of software vendors have generally several stages during the lifetime of the product they support, generally a first one which is the polishing of the release where they can even add new features, another one where they only backport (critical) bug fixes, and a final one where they only backport security related bug fixes. So, maybe we could have a 2 phase process: - First 6 months: backport of bug fixes with the same criteria as we do currently - Last 6 months: only critical bug fixes (crashes, data loss) (or 9 months / 3 months, whatever...) But if we're really in that mode, that should not only apply to QGIS but to its dependent libraries as well. Basically this would mean that for OSGeo4W, you should have 2 distinct sets for the dependencies: one frozen (or with very controlled changes) for the LTR, and a living one for the new versions. Even -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer