Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 330158

Summary: Remove org.eclipse.gef.ui.console, org.eclipse.gef.ui.console.icons, org.eclipse.gef.ui.stackview, and org.eclipse.gef.ui.stackview packages, which are deprecated and marked for deletion since 3.1
Product: [Tools] GEF Reporter: Alexander Nyßen <nyssen>
Component: GEF-Legacy GEF (MVC)Assignee: gef-inbox <gef-inbox>
Status: RESOLVED WONTFIX QA Contact:
Severity: normal    
Priority: P3 CC: ahunter.eclipse
Version: 3.7   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:

Description Alexander Nyßen CLA 2010-11-12 18:11:48 EST 
Classes in org.eclipse.gef.ui.console and org.eclipse.gef.ui.stackview have been deprecated in 3.1, mentioning that they will get deleted.
Comment 1 Alexander Nyßen CLA 2010-11-12 18:15:42 EST 
All classes in the respective packages have been marked as deprecated in 3.1, mentioning that they will be removed in the future. 

Due to API retention policy the respective classes could already have been deleted in 3.4. Anthony, do you think we can remove those packages in 3.7?
Comment 2 Anthony Hunter CLA 2010-11-15 10:13:36 EST 
If we remove the API then API tooling will force us to make the version of the bundle 4.0. Since we do not want this, we need to hold off the deletion for now.
Comment 3 Alexander Nyßen CLA 2010-11-15 12:16:17 EST 
Well, as far as API-tooling is concerned, we may technically deal with this by creating a "commented version number problem filter" (quick fix in MANIFEST.MF). 

The interesting question is whether deprecation policy allows us to removed deprecated API  without increasing the version number. API central (http://wiki.eclipse.org/Eclipse/API_Central/Deprecation_Policy) does not state anything concrete about version numbers w.r.t. such a scenario (at least I could not find any hint there). It simply states what prerequisites have to be fulfilled for a removal of deprecated API, namely: 

1) the respective API has to be marked as deprecated since a sufficient long time-frame
2) the removal of the API has been announced since a sufficient long time-frame.
3) PMC approval is required.

As 1) and 2) definitely hold for the respective code, 3) should not be a problem. 

Looking at it from another perspective: as far as I understand, a major version increment would allow us to change/remove any kind of API (even without having to deprecate it beforehand; and definitely without a PMC approval), so why would there be a need for such a deprecation policy, if we could circumvent it by simply increasing the major version number?
Comment 4 Alexander Nyßen CLA 2014-07-12 11:33:58 EDT 
Resolving as wontfix. As it seems no API has ever been removed from the GEF bundle, there is no urgent need to start with it now. GEF4 will come up with an alternative (GEF4 MVC) anyway, so there is no urgent need to break and GEF (MVC) adopters.