I agree with Even: deprecation with a clear warning seems the best solution.
On Tue, Jan 20, 2026 at 12:29 AM Even Rouault via QGIS-Developer <[email protected]> wrote: > > Nyall, > > I don't have particular knowledge about that bit, but your plan sounds > good. Is there a way we could emit runtime deprecation warning "You are > using a deprecated QGIS 2 Python API for custom parameter GUI widgets > that is going to be removed in a later QGIS 4.x release. Proceed to > migrating it to newer C++ based processing classes ASAP" (or something > like that) that would be user visible (in log panel e.g., or maybe even > a notification. Bonus point if we can mention the component/plugin that > triggered the warning). Generally I think this strategy could be used in > other similar instances. Gradual removal of advertized deprecated APIs > rather than doing everything at once during n->n+1 upgrades might be > more practical for us to do > > Even > > Le 20/01/2026 à 00:15, Nyall Dawson via QGIS-Developer a écrit : > > Hey list, > > > > Soo.. back when we were planning 4.0 and deciding if we would break > > any of the QGIS api, we made the decision that none of the existing > > deprecated API was particularly painful and could be dragged along > > with 4.x without too much effort. > > > > I've come to the realisation that there's an exception here -- the old > > Processing 2.x purely python based API for custom parameter GUI > > widgets. This is/was a pure Python API that was kept in 3.0, because > > at that stage we hadn't yet moved any of the Processing GUI classes to > > c++. When the c++ GUI classes were introduced we had to keep a lot of > > crufty code and Python messiness to avoid breaking this. It's been > > painful to drag through to 3.44, and it's going to be even more > > painful to maintain throughout 4.x. (Especially given the heavy churn > > that's currently going on in the model designer, eg > > https://github.com/qgis/QGIS/pull/64591). > > > > In retrospect I think we should have made an exception to the "no > > PyQGIS API breakage for 4.0" rule and dropped all of that old API for > > 4.0. Unfortunately it's too late to do this now -- it's not as simple > > as just deleting a bunch of deprecated code. Rather the roots of the > > hackiness and old API are very deep, and there's a non-trivial amount > > of (complex, challenging) work associated with pulling out these roots. > > > > So -- I'd like to propose that we approach this by making it very > > clear in the 4.0 release notes that the old Processing 2.x API is > > considered completely deprecated, that it is no longer considered part > > of stable API, and that it WILL be removed at some stage during the > > lifespan of 4.x. We don't advertise a fixed schedule for this, but > > state that "When preparing for 4.0 support, plugin authors should port > > their plugins away from the deprecated Processing GUI API to ensure > > that they will work for all future 4.x releases". > > This would buy us time to do a proper considered removal of that API, > > while ensuring that we aren't blocked from implementing nice changes > > to Processing and the modeler when that API becomes impossible to work > > around anymore. > > Thoughts? > > > > Nyall > > > > > > _______________________________________________ > > 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 > > -- > http://www.spatialys.com > My software is free, but my time generally not. > > _______________________________________________ > 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 -- Alessandro Pasotti QCooperative: www.qcooperative.net ItOpen: www.itopen.it _______________________________________________ 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
