[wtp-pmc] API change "guidelines"

[Chuck Bridgham <cbridgha@xxxxxxxxxx>]

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

	Phone: 1-919-254-1848 E-mail: cbridgha@xxxxxxxxxx	4205 S Miami Blvd Durham, NC 27703-9141 United States