On Wed, Oct 2, 2019 at 12:22 PM Even Rouault <even.roua...@spatialys.com> wrote:
> > 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...) > > This looks a good approach to me. > 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 > Yes, that makes sense too. -- Alessandro Pasotti w3: www.itopen.it
_______________________________________________ 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
