Community
Participate
Working Groups
For example we can remove the non generic factories and move the generic ones to the original package.
We should avoid breaking API no moving new API to old one is a no-go. Deletion needs to be planned. See here https://wiki.eclipse.org/Eclipse/API_Central/Deprecation_Policy For the old factories Jens already did that plan for the September 2022 release, see https://htmlpreview.github.io/?https://raw.githubusercontent.com/eclipse/eclipse.platform.common/master/bundles/org.eclipse.platform.doc.isv/porting/removals.html
That's why I suggest a "databinding 2.0" so there is no need to keep old/problematic code forever.
(In reply to Christoph Laeubrich from comment #2) > That's why I suggest a "databinding 2.0" so there is no need to keep > old/problematic code forever. -2, so far the databinding framework was enhanced with API breakage, I see no need to change that now. It is tempting to redo everything but platform development needs to try to stay api compliant.
So what do you suggest then to remove inconsistencies and keep the code maintainable in the future?
(In reply to Christoph Laeubrich from comment #4) > So what do you suggest then to remove inconsistencies and keep the code > maintainable in the future? Improve it like we did in the past, see the db generics works or the new db factory work. If something is really bad provide new API and use https://wiki.eclipse.org/Eclipse/API_Central/Deprecation_Policy for the old API which allows you to remove it in 2 years if you follow the process.
(In reply to Lars Vogel from comment #5) > Improve it like we did in the past I just wanted to prevent more code duplication, but if that's the only way to go I'll check how it could be archived in such a way. I'll change the resolution to invalid here to reflect that the proposed idea itself is invalid but could be fixed in other terms.
