[Sugar-devel] Activity updates
walter.bender at gmail.com
Thu Oct 21 10:14:52 EDT 2010
On Tue, Oct 19, 2010 at 9:28 PM, Bernie Innocenti <bernie at codewiz.org> 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.
> 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.
I hope there are better examples. Turtle Art has never had sensor
support, so it cannot be broken. Turtle Art with Sensor, a separate
activity, has never been loaded onto ALSO, since I never got it
working on recent builds/hardware.
> 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.
> // Bernie Innocenti - http://codewiz.org/
> \X/ Sugar Labs - http://sugarlabs.org/
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
More information about the Sugar-devel