Changes

* variety of Sugar activities

* variety of Sugar activities

* that use variety of Sugar Services

* that use variety of Sugar Services

So, developers use a set of services that have their own API changes based schedules. Glucose could be [[Documentation Team/Services/Native packages usage|wrapped]] to regular service(s) with proper API changes based major versions e.g. if glucose's activity API wasn't changed since 0.82(glucose-0.x service) all activities that requires ''glucose 0'' will be launched but instead of launching activities with requirements ''glucose 1'', user will be warned about outdated sugar environment.

So, developers use a set of services that have their own [[Documentation_Team/Services/Service_Developers_Guide#Versioning_scheme|API changes based]] schedules. Glucose could be [[Documentation Team/Services/Native packages usage|wrapped]] to regular service(s) with proper API changes based major versions e.g. if glucose's activity API wasn't backwards compatibility broken since 0.82(glucose-0.x service) all activities that requires ''glucose 0'' will be launched but instead of launching activities with requirements ''glucose 1'', user will be warned about outdated sugar environment.

The corner stone of Sugar Services proposal is [[Activity_Team/Services/Saccharin|Saccharin]] library. This library provides installing/upgrading (via 0install) mechanism for services. The rest of services is just variety of libraries/applications/native-packages. Saccharin could be a part of glucose (some of its releases) or bundled to .xo otherwise.

The corner stone of Sugar Services proposal is [[Activity_Team/Services/Saccharin|Saccharin]] library. This library provides installing/upgrading (via 0install) mechanism for services. The rest of services is just variety of libraries/applications/native-packages. Saccharin could be a part of glucose (some of its releases) or bundled to .xo otherwise.