5,705
edits
Changes
→Proposal Goals
* backwards compability
* backwards compability
* (http://wiki.sugarlabs.org/go/Development_Team/sugar-port will take care for the activities needs for a working activity on 0.82 for example)
* (http://wiki.sugarlabs.org/go/Development_Team/sugar-port will take care for the activities needs for a working activity on 0.82 for example)
<strong>Decoupling of Sucrose</strong>
The major idea is to have tough core(with stable release cycle) + unlimited count of activities.<br>
It could looks like:
* core(glucose), six months(or so) release cycle, w/o any activities only API
* bridge([[Development_Team/sugar-port|sugar-port]] for example) between all(in ideal) already deployed sugars and activities i.e. it provides backwards compatibility(so the same activity code will work on all sugars) and at the same time provides features from newest sugar(so the same activity code will use last sugar's features)
* the rest of sugar world i.e. fructose/honey (but now there is no differences between them)
And of course deployers can form any sets from these components
<strong> Old items </strong>
<strong> Old items </strong>