Difference between revisions of "Development Team/API policy"

From Sugar Labs
Jump to navigation Jump to search
(New page: == Policy == Each interface, being a python module, a service or a protocol can be in one of the following states. The state should be always explicitly documented. === Unstable === Cha...)
 
Line 17: Line 17:
 
== Current state ==
 
== Current state ==
  
* Datastore DBus service - UNSTABLE
+
* Datastore DBus service - STABLE
 
* Presence DBus service - UNSTABLE
 
* Presence DBus service - UNSTABLE
 
* Window management protocols - UNSTABLE
 
* Window management protocols - UNSTABLE
 
* jarabe python package - UNSTABLE
 
* jarabe python package - UNSTABLE
 
* sugar python package - detailed in the documentation.
 
* sugar python package - detailed in the documentation.

Revision as of 07:04, 28 October 2008

Policy

Each interface, being a python module, a service or a protocol can be in one of the following states. The state should be always explicitly documented.

Unstable

Changes are possible at any time, except after the feature freeze of each release cycle, but they should be well documented. It should be used for API which requirements are not yet well enough to be able to settle on a stable interface. As Sugar mature we should aim to have as little as possible components in this state.

Stable

No *incompatible* change is possible. The API should be well documented and a set of unit tests should prevent breakage. To be able to remove a stable interface it will have to first be deprecated.

Deprecated

Interfaces which are not useful anymore or are being replaced by better, incompatible ones should be deprecated and removed in the next *major* version. When deprecating an interface a replacement should be available and the migration to it well documented.

Current state

  • Datastore DBus service - STABLE
  • Presence DBus service - UNSTABLE
  • Window management protocols - UNSTABLE
  • jarabe python package - UNSTABLE
  • sugar python package - detailed in the documentation.