[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.