Platform Team/Package Management System: Difference between revisions

Line 53:

* variety of Sugar activities

* that use variety of Sugar Services

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.

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 [[Documentation_Team/Services/Service_Developers_Guide#Versioning_scheme|versioning scheme]] as well 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.

@@ Line 53: / Line 53: @@
 * variety of Sugar activities
 * that use variety of Sugar Services
-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.
+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 [[Documentation_Team/Services/Service_Developers_Guide#Versioning_scheme|versioning scheme]] as well 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.