Development Team/API 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.
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.
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.
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.
Datastore DBus service
Window management protocols
Presence DBus service
UNSTABLE. It was developed in the early Sugar days without a clear idea of the actual requirements. A large part of it is used only by jarabe and will be made internal to it. We have a stable python wrapper which is what most activities uses anyway.
jarabe python package
UNSTABLE. We are working on extensibility of the core components provided by jarabe, but we don't have enough resources to maintain a stable API, nor a clear idea of the requirements yet. We will be moving towards stability but since it's not a basic, essential part of the system, we are punting on it for now.
sugar python package
The state is different for each module. See the documentation for details.