Changes

== Purposes ==

== Purposes ==

Sugar is not unique when faced with questions like how to deploy new features to users. There are well-tested and robust models in the FOSS world when projects follow regular release schedules, e.g., 6-month, support, long-time supported releases, etc. But there could be cases when Sugar has its specific needs:

Sugar is not unique when faced with questions such as how to deploy new features to users. There are well-tested and robust models in the FOSS world for projects that follow regular release schedules, e.g., 6-month, support, long-term supported releases, etc. But, there may be cases where Sugar has its own specific needs:

* The most broad Sugar audience is teachers, students, schools and other educational organizations. Thus, we can not rely in all cases on the fact that all Sugar users will use only the latest stable Sugar release. For example, the latest OLPC Sugar is 0.82, next will be 0.84, but the latest stable version is 0.88.

* The most broad Sugar audience includes teachers, students, schools and other educational organizations. Thus, we can not rely on the supposition that all Sugar users will use only the latest stable Sugar release. For example, the latest OLPC Sugar is <s>0.82, next will be 0.84, but the latest stable version is 0.88</s>.

* Many developers participate on a casual basis, thus, supporting several Sugars (one for stable OLPC, one for next stable OLPC, and one for the latest stable upstream) for their activities is overkill. As such, people support only one branch, and either drop other user categories, or do not implement useful features from the latest Sugar (like the new toolbar design).

* Many developers participate on a casual basis, thus, supporting several Sugars (one for stable OLPC, one for next stable OLPC, and one for the latest stable upstream) for their activities is too much work for them. As such, people support only one branch, and either drop other user categories, or do not implement useful features from the latest Sugar (like the new toolbar design).

* One of original Sugar purposes is stimulating people to hack existing code and share their code. Having (in the ideal case) such a huge heap of code, we can't rely on the chance that all these activities will work on a bunch of Sugar releases. For example, if someone took the Record activity (maybe not the last version) and implemented a new feature, and then he just wants to share his hack, but not test this new code on several Sugar Platforms, or ask QA to test it, or ask ASLO editors to review etc., just share in a casual but still useful manner.

* One of Sugar's original purposes is stimulating people to hack existing code and share their code. Having (in the ideal case) such a huge heap of code, we can't rely on the chance that all these activities will work on so many Sugar releases. For example, someone may take the Record activity (maybe not the last version) and implement a new feature. Then, he just wants to share his hack, but not test this new code on several Sugar Platforms, or ask QA to test it, or ask ASLO editors to review, etc., just share it in a casual but still useful manner.

So, the right answer could be a more scalable and decentralized development model. That doesn't mean we should follow only a decentralized model, but we can effectively mix both&mdash;a centralized model with the core team that features regular releases&mdash;and add an optional, decentralized model.

So, the right answer could be a more scalable and decentralized development model. That doesn't mean we should follow only a decentralized model, but we can effectively mix both&mdash;a centralized model with the core team that features regular releases&mdash;and add an optional, decentralized model.

== Implementation ideas ==

== Implementation ideas ==

Activity development could be based on two software-level solutions that are tied to each other.

Activity development could be based on a pair of software-level solutions that are tied to each other.

=== Intermediate level libraries ===

=== Intermediate level libraries ===

=== 0install deployment mechanism ===

=== 0install deployment mechanism ===

Intermediate level libraries will be especially useful if their recent versions could be installed on every Sugar in the field whatever the Sucrose release on a particular machine. 0install is an obvious choice since it is:

Intermediate level libraries will be especially useful if their recent versions could be installed on every Sugar in the field, whatever the Sucrose release on a particular machine. 0install is an obvious choice since it is

* An overall GNU/Linux distribution mechanism,

* An overall GNU/Linux distribution mechanism,

== Activity developer's point of view ==

== Activity developer's point of view ==

Having covered all the above, an activity developer needs only one thing to be sure that his activity will work on all Sugars in the field: Declare what intermediate libraries are needed and, maybe, what particular versions are needed. See [[Documentation_Team/Services/Activity_Developers_Guide#Using_services|Activity Developers Guide]] to learn how it is implemented in 0sugar.

Having covered all the above, an activity developer needs only assure one thing to be sure that his activity will work on all Sugars in the field: Declare what intermediate libraries are needed and, maybe, what particular versions are needed. See [[Documentation_Team/Services/Activity_Developers_Guide#Using_services|Activity Developers Guide]] to learn how it is implemented in 0sugar.

So, to support a huge repository of Learner's/doer's code (see 3rd point of [[#Purposes|purposes]]), there is no need in having a huge QA effort to review every new piece of code, we just rely on the activity coder having declared all required libraries/versions (he can just type all versions he had during activity coding).

So, to support a huge repository of Learner's/doer's code (see 3rd point of [[#Purposes|purposes]]), there is no need in having a huge QA effort to review every new piece of code&mdash;we just rely on the activity coder having declared all the required libraries/versions (those used during activity coding).