+1 to drop the old Processing 2.x API in the future 4.x release. But as mentioned by Even and Alessandro, it would be nice to make this deprecation warning clearly visible.
пн, 19 січ. 2026 р. о 23:16 Nyall Dawson via QGIS-Developer <[email protected]> пише: > > 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 -- Alexander Bruy _______________________________________________ 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
