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 "WTP API Change History"
| Line 19: | Line 19: | ||
<br> | <br> | ||
| − | == WTP API Change History == | + | == WTP API Change History == |
The keyword: "api" should be used to mark bugs that alter an api in any way. | The keyword: "api" should be used to mark bugs that alter an api in any way. | ||
| − | :[https://bugs.eclipse.org/bugs/buglist.cgi?keywords=api | + | :[https://bugs.eclipse.org/bugs/buglist.cgi?classification=WebTools&keywords=api&keywords_type=allwords&query_format=advanced&order=bug_id%20DESC&query_based_on= Here is the current bug list] |
| − | + | ||
| − | + | ||
== links == | == links == | ||
Latest revision as of 10:45, 25 October 2011
Contents
WTP API "Guidelines"
Thinking of making a change that effects a public or private api? Our goal is to maintain a stable, low risk, and safe environment for maintenance releases, while also allowing a flexible but well documented policy for API change in any current development release. These guidelines should help determine the best course of change to a component.
Maintenance release
- Breaking changes to public API is never allowed.
- Non-breaking changes to public API is discouraged but exceptions must be reviewed by the PMC.
- Changes to existing internal api is discouraged, and an new alternate api is always preferred.
- If making a change to an existing Interface class, always consider adding an extension interface to prevent breaking adopter implementers.
- API also includes extensions point declarations and implementations if backing api classes (Example: Facet/Runtime extensions and classes).
- Adding features in a maintenance release is discouraged, exceptions should be brought to PMC, and a separate feature release should be considered to minimize adopter risk.
Current or Maintenance release
- In any release (maintenance or current) any api change that causes backward compatibility breakage must be reviewed by the PMC.
- Any non-breaking change to an existing api in a current release is allowed but should be well documented, and shared with the community.
WTP API Change History
The keyword: "api" should be used to mark bugs that alter an api in any way.
links