Bug 566755

Summary:	[Databinding 2.0] remove deprecated methods, classes and packages
Product:	[Eclipse Project] Platform	Reporter:	Christoph Laeubrich <laeubi>
Component:	UI	Assignee:	Platform-UI-Inbox <Platform-UI-Inbox>
Status:	RESOLVED INVALID	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	Lars.Vogel
Version:	4.14
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:
Bug Depends on:
Bug Blocks:	566750

Description Christoph Laeubrich

2020-09-08 01:39:08 EDT

For example we can remove the non generic factories and move the generic ones to the original package.

Comment 1 Lars Vogel

2020-09-08 01:56:12 EDT

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

Comment 2 Christoph Laeubrich

2020-09-08 02:17:00 EDT

That's why I suggest a "databinding 2.0" so there is no need to keep old/problematic code forever.

Comment 3 Lars Vogel

2020-09-08 02:26:26 EDT

(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.

Comment 4 Christoph Laeubrich

2020-09-08 02:36:37 EDT

So what do you suggest then to remove inconsistencies and keep the code maintainable in the future?

Comment 5 Lars Vogel

2020-09-08 02:39:02 EDT

(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.

Comment 6 Christoph Laeubrich

2020-09-08 02:47:37 EDT

(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.