[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[eclipse.org-architecture-council] [Bug 261544] New: Need a process and policy for API deprecation
|
https://bugs.eclipse.org/bugs/show_bug.cgi?id=261544
Product/Component: Community / Architecture Council
Summary: Need a process and policy for API deprecation
Product: Community
Version: unspecified
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P3
Component: Architecture Council
AssignedTo: eclipse.org-architecture-council@xxxxxxxxxxx
ReportedBy: martin.oberhuber@xxxxxxxxxxxxx
In order to allow continued innovation at Eclipse, we'll need to start
deprecating stuff to get rid of it eventually - especially in the light of the
upcoming e4. We should start marking stuff as "deprecated" (soft or hard) as
soon as possible, in order to get the ball rolling. We can only measure usage
of deprecated stuff if we start tagging stuff as deprecated somehow. To do
that, we need to have communication channels in place as well as a policy that
describes what the various kinds of deprecation mean.
Based on the discussion on
http://wiki.eclipse.org/Architecture_Council/Meetings/API_Deprecation_20080119
This bug is for discussing the API deprecation process and policies that the
Architecture Council recommends to the Projects. We should start moving our
feelings into a Wiki page as soon as we get some consensus (and a volunteer to
actually create the Wiki page. Discussion is open!
Reasons for deprecation:
- Simplify APIs, reduce bloat, reduce burden of creating new API
Challenges of deprecation:
- Legacy Binary bundles, getting feedback (tools, communication channels)
- community expectations, value/cost
- Eclipse-wide consistency vs. different project maturity levels
Ideas for moving forward:
- Start creating a Wiki document with deprecation rules and wording
- Work on tools to measure usage of deprecated API (also in binary bundles)
- Create a "soft deprecation" if the new story is not complete
- Think about how to best sell deprecation to clients/consumers
Questions:
- What is the role of the Train (do we require API-clean or not)?
- What should be the semantics of deprecation (2 trains, 1 major bump, ...)?
- Who's going to work on (policies, documentation, comm.channels, tools)
--
Configure bugmail: https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.