5,705
edits
Changes
Jump to navigation
Jump to search
Line 235:
Line 235: + +
→Decoupling of Sucrose
It could looks like:
It could looks like:
* '''core''' - glucose, six months(or so) release cycle, w/o any activities, only API
* '''core''' - glucose, six months(or so) release cycle, w/o any activities, only API
** in ideal, it should have only dbus 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)
* '''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)
** we could write this level in vala to provide core functionality for the wide range of platforms
* '''world''' - the rest of sugar world i.e. fructose/honey (but now there are no differences between them) that use core directly, if all deployed sugars have the same API for desired functionality(for example in case of preselected mime type, ObjectsChooser has different API for 0.82-0.86), or use bridge otherwise.<br>imho another point to have activities outside of core release cycle - activities have more shorter release cycle then core has
* '''world''' - the rest of sugar world i.e. fructose/honey (but now there are no differences between them) that use core directly, if all deployed sugars have the same API for desired functionality(for example in case of preselected mime type, ObjectsChooser has different API for 0.82-0.86), or use bridge otherwise.<br>imho another point to have activities outside of core release cycle - activities have more shorter release cycle then core has