Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Architecture Council/Meetings/API Deprecation 20080119"
| Line 14: | Line 14: | ||
= Notes = | = Notes = | ||
* See [[Architecture Council/Minutes January 15 2009#New Topics]] for previous discussions | * See [[Architecture Council/Minutes January 15 2009#New Topics]] for previous discussions | ||
| − | * Goal is to come up with enough agreement to create initial rules / guidelines for review | + | * 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 | ||
| + | |||
| + | = Reasoning = | ||
| + | * 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. | ||
| + | * Consider other technologies: | ||
| + | ** Deprecation in Java | ||
| + | ** Evolution of glibc | ||
| + | |||
| + | = Questions = | ||
| + | * 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 = | = Next Meeting = | ||
Revision as of 12:44, 16 January 2009
| Meeting Title: | AC Call on API Deprecation |
| Date & Time: | Thursday January 22, 2009 at 1700 UTC / 0900 SFO / 1200 Ottawa / 1800 Berlin HTML |  iCal
|
| Dial-in: | (+1) 613.287.8000 (Ottawa and international) or 866.362.7064 (toll-free North America) passcode 464440# |
Attendees
Notes
- See Architecture Council/Minutes January 15 2009#New Topics for previous discussions
- 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
Reasoning
- 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.
- Consider other technologies:
- Deprecation in Java
- Evolution of glibc
Questions
- 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?