[Sugar-devel] Activity updates

Gary Martin garycmartin at googlemail.com
Thu Oct 21 09:47:38 EDT 2010

On 19 Oct 2010, at 22:28, Bernie Innocenti wrote:

> Quoting you from IRC:
> <garycmartin> 09:36:21> bernie: Was it you that mentioned that
> deployments did not want to point to ASLO for update as version were not
> being flagged correctly for Sugar release compatibility?
> <garycmartin> 09:45:09> bernie: FWIW, I've just been through 60+
> activities testing ASLO installs on a clean XO-1 0.82 build (0.84 is
> next on my todo list). I only found 4 activities that didn't have an old
> enough past version uploaded for that release of Sugar, and only one
> activity that failed to launch due to a trivial file permission error in
> the bundle (SL#2464).
> Indeed, almost all activities are compatible across 0.84-0.88. Probably
> also 0.90.

0.90 has been a little rough so far on Activities, not really Sugar changes, but all the churn going on in F14 dependencies. 0.92 is likely going to be much, much more painful, with perhaps the majority of existing activities breaking, and requiring a maintenance release just to launch. :(

> But the point is that deployments really need to ensure that the
> activity works with their lesson plans. For example, Turtle Art's
> sensors support has been broken for a while in ASLO.
> At any time someone could upload a new version of an activity that
> breaks some feature that deployments were relying upon. Without
> interposing an interim QA stage, possibly done by the deployment's
> education team, ASLO cannot be relied upon for updates.
> My proposed solution consits in reviving the microformat protocol for
> activity updating (already done by Anish) and then augment the existing
> concept of "collections" in ASLO to let deployments specify a particular
> bundle version.

Yes, deployment owned/managed collections that can specify activity versions sounds like a fair plan, ideally with the software update control panel using a deployment configured setting (gconf) so the owner can easily stay in sync with changes to the collection as deployments QA new activity releases. I guess we're still in a holding pattern for a move to the Python version of the ASLO backend.


> -- 
>   // Bernie Innocenti - http://codewiz.org/
> \X/  Sugar Labs       - http://sugarlabs.org/
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel

More information about the Sugar-devel mailing list