Development Team/API policy

< Development Team
Revision as of 07:01, 28 October 2008 by Marcopg (talk | contribs) (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...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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 - UNSTABLE
  • Presence DBus service - UNSTABLE
  • Window management protocols - UNSTABLE
  • jarabe python package - UNSTABLE
  • sugar python package - detailed in the documentation.