Difference between revisions of "WTP API Change History"

Revision as of 10:42, 25 October 2011

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.

Here is the current bug list

links

WTP API page

Eclipse API Central