Skip to main content
Jump to: navigation, search

Difference between revisions of "Architecture Council/Meetings/API Deprecation 20080119"

m (Attendees)
Line 31: Line 31:
| '''Modeling'''
| '''Modeling'''
| Ed Merks
| Ed Merks
| Obeo
| '''Modeling'''
| Cédric Brun
| OC Systems
| OC Systems

Revision as of 11:32, 19 January 2009

Meeting Title: AC Call on API Deprecation
Date & Time: Monday January 19, 2009 at 1600 UTC / 0800 SFO / 1100 Ottawa / 1700 Berlin
Html.gifHTML | Ical.gifiCal
Dial-in: (+1) 613.287.8000 (Ottawa and international) or
866.362.7064 (toll-free North America)
passcode 464440#
Backup Dial-in: International +44 (0)1452 567588 / Freephone +1 (866) 6161738 / Passcode: 0587322148 #


Company Eclipse Project Attendees
Eclipse Foundation Technology, Tools Bjorn Freeman-Benson
IBM Eclipse Project John Arthorne, Boris Bokowski, Philippe Mulet
Macro Modeling Modeling Ed Merks
Obeo Modeling Cédric Brun
OC Systems TPTP Oliver Cole
STAR WTP Dave Carver
Wind River DSDP Martin Oberhuber, Michael Scharf
EclipseSource PDE Chris Aniszczyk

Missing: BIRT, DTP, RT, STP, consumer rep, strategic reps



  • Eclipse APIs become ever more complicated and duplicated, making it harder and harder to understand.
  • For e4 at least, we should make it simpler to code against Eclipse. We should get rid of unnecessary burden to make ourselves ready for the future.
  • We need to talk about Deprecation policies NOW to incorporate them into Galileo (and thus be able to get rid of deprecated stuff sooner).
  • Consider other technologies:
    • Deprecation in Java
    • Evolution of glibc


  • Should the deprecation rules be the same for all projects, or different from project to project?
  • By what channels can the Community be informed about deprecating API?
  • How long does deprecated API need to stay around? Does it depend from case to case?

Next Meeting

Back to the top