Summary: | Adapt Zest to changes in layout | ||||||
---|---|---|---|---|---|---|---|
Product: | [Tools] GEF | Reporter: | Mateusz Matela <mateusz.matela> | ||||
Component: | GEF-Legacy Zest | Assignee: | gef-inbox <gef-inbox> | ||||
Status: | NEW --- | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | P3 | CC: | ahunter.eclipse, irbull | ||||
Version: | 3.6 | ||||||
Target Milestone: | --- | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Whiteboard: | |||||||
Bug Depends on: | 283083 | ||||||
Bug Blocks: | |||||||
Attachments: |
|
Description
Mateusz Matela
2009-07-10 15:00:29 EDT
Created attachment 141333 [details]
patch
A reminder that our next release is a point release 3.6 so we cannot remove any public API. If you point your API tools to the previous GEF release you can see any API breakage errors. I thought API was on the bundle level, not project level. For example, in Eclipse, p2 bundles are marked 1.0, while other bundles (PDE for example) are at 3.5. So the Zest bundle could be incremented. Zest has a small community (compared to GEF for example) and the benefits of cleaning up some of the old API (some of which didn't work anyways), IMHO, outweighs strict API stability. Now, I'm not suggesting we completely re-write our API, but there are some cases that cleanup will be a welcomed change. This topic came up on the RT-PMC: http://dev.eclipse.org/mhonarc/lists/rt-pmc/msg00716.html and Tom Watson had some good comments here: http://dev.eclipse.org/mhonarc/lists/rt-pmc/msg00747.html cheers, ian I filed Bug 283252 to discuss the possibility of moving from Zest 1.1 to Zest 2.0. The guidelines here should be to deprecate the old API and add new ones. Current guidelines from the architecture council is that deprecated API needs to stay in for two years. |