Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[wtp-pmc] API change "guidelines"

Here is my first pass at a "API change guidelines" that we will add to our API wiki page.   Please comment.

I plan on discussing this in our meeting tomorrow.

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.

Thanks - Chuck

Chuck Bridgham
RAD Architect, Java EE Tools, WTP PMC

2D barcode - encoded with contact information Phone: 1-919-254-1848

4205 S Miami Blvd
Durham, NC 27703-9141
United States

Back to the top