Jump to: navigation, search

Difference between revisions of "WTP API Policy"

m (New page: = WTP API Policy = In previous releases WTP did not have enough API to meet our adopter's needs and was causing repeated breakage as we changed our internal code. This led to the adoption...)
 
m (WTP API Policy)
Line 1: Line 1:
 
= WTP API Policy =
 
= WTP API Policy =
  
In previous releases WTP did not have enough API to meet our adopter's needs and was causing repeated breakage as we changed our internal code. This led to the adoption of an internal usage scan policy - if any adopter was willing to supply usage data for WTP, we agreed not to change any of the internal code used by the adopter.
+
'''''DRAFT'''''
  
 +
In previous releases WTP did not have enough API to meet our adopter's needs and was causing repeated breakage to adopters as we changed our internal code. This led to the adoption of an internal usage scan policy - if any adopter was willing to supply usage data for WTP, we agreed not to change any of the internal code used by the adopter.
  
 +
This policy was required at the time to stabilize WTP and encourage widespread adoption. However, continuing this policy indefinitely  hampers WTP
  
 
:grandfather date
 
:grandfather date
Line 9: Line 11:
  
  
== Internal Usage Scans ==
+
== Grandfathering of Internal Usage Scans ==
  
  

Revision as of 20:58, 22 October 2007

WTP API Policy

DRAFT

In previous releases WTP did not have enough API to meet our adopter's needs and was causing repeated breakage to adopters as we changed our internal code. This led to the adoption of an internal usage scan policy - if any adopter was willing to supply usage data for WTP, we agreed not to change any of the internal code used by the adopter.

This policy was required at the time to stabilize WTP and encourage widespread adoption. However, continuing this policy indefinitely hampers WTP

grandfather date
legitimate usage


Grandfathering of Internal Usage Scans

Legitimate Internal Usage

The following are some examples of illegitimate internal usage:

  • Use of messages, icons, logging or tracing methods from another plugin
  • Use of internal methods where equivalent API has existed for some time

The following are some examples of legitimate internal usage:

  • Use of internal methods where no equivalent API exists

Deprecation

API

API should not be deprecated unless absolutely necessary and reviewed by project lead. Deprecated API may not be removed for at least 2 major releases. Exceptions must be approved by the PMC.

Provisional API

Provisional API is ** in the process of becoming API.

Provisional API that is declared in a milestone may be changed or removed at any time.

Provisional API that is declared in a release

Internal usage

Internal usage reported in adopter usage scans must be maintained as true API.