WTP API Change History
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