Architecture Council/Meetings/API Deprecation 20080119
|Meeting Title:||AC Call on API Deprecation|
|Date & Time:|| Monday January 19, 2009 at 1600 UTC / 0800 SFO / 1100 Ottawa / 1700 Berlin|
HTML | iCal
|Dial-in:|| (+1) 613.287.8000 (Ottawa and international) or|
866.362.7064 (toll-free North America)
|Backup Dial-in:||International +44 (0)1452 567588 / Freephone +1 (866) 6161738 / Passcode: 0587322148 #|
- Doodle Poll for scheduling
|Eclipse Foundation||Technology, Tools||Bjorn Freeman-Benson|
|IBM||Eclipse Project||John Arthorne, Boris Bokowski, Philippe Mulet|
|Macro Modeling||Modeling||Ed Merks|
|OC Systems||TPTP||Oliver Cole|
|Wind River||DSDP||Martin Oberhuber, Michael Scharf|
Missing: BIRT, DTP, RT, STP, consumer rep, strategic reps
- See Architecture Council/Minutes January 15 2009#New Topics for previous discussions
- Part of the larger story on Eclipse Adoption.
- Goal is to
- Define the questions that we'd like to get answered
- come up with enough agreement to create initial rules / guidelines for review
- 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?