Sugar Services makes sense only for activities that have non-Sugar Platform dependencies or support more then one Sucrose release cycle.
+
Sugar Services makes sense for activities that have non-Sugar Platform dependencies or support more then one Sucrose release cycle.
−
For such activities, development focus is shifting from Sucrose to API of services they are using. More over activity could be stuck to particular service API version (of course if service developers still support this branch) and Sugar Services will support several branches for the same service simultaneously.
+
For such activities, development focus is shifted from Sucrose to an API of services they are using. More over, an activity could be assigned to particular service API version (provided that service developers still support this branch); Sugar Services will support several branches for the same service simultaneously.
−
To utilize Services benefits, activity developer just need to [[Activity Team/Documentation/Services/Activity Developers Guide|mention all services(or pure 0install feeds)]] that activity is using. Services infrastructure will provide specified services(and specified versions) for activity and will export environment variables, like LD_LIBRARY_PATH or PYTHONPATH, to activity session, so activity developer shouldn't adapt code to Services.
+
To utilize Services benefits, activity developer need only to [[Activity Team/Documentation/Services/Activity Developers Guide|mention all services (or pure 0install feeds)]] that their activity is using. Services infrastructure will provide specified services (and specified versions) for the activity and will export environment variables, e.g., LD_LIBRARY_PATH or PYTHONPATH, to activity session. ''Activity developer need not to adapt their code to Services.''
=== Use of non-Sugar Platform dependencies in activities ===
=== Use of non-Sugar Platform dependencies in activities ===