[sugar] Activity versioning schema
gregsmitholpc at gmail.com
Wed Jul 16 13:16:51 EDT 2008
Thanks for the status. I wasn't asking if we have agreement. I was
asking who will update the incorrect documentation when/if we have
something new to say.
You seem to know the state of affairs, can you update this wiki link
http://wiki.laptop.org/go/Activity_bundles so it does not say anything
which is incorrect per Gary's suggestion below?
I'm trying to lay down some covering fire here so Gary makes it the door
in one piece :-)
(perhaps http://wiki.laptop.org/go/Activity_bundles *** would be a
start), so us external activity developers don't have to be part of
this bit punk talk.
*** Salient quotes: "Each activity.info file must have a
"activity_version" key. The version is a single positive integer.
Larger versions are considered "newer". The value assigned to this key
should be considered opaque to the activity; the only requirement of
the activity is that it must be larger for new activity builds." And:
"Each activity.info file must have a "host_version" key. The version
is a single positive integer. This specifies the version of the Sugar
environment which the activity is compatible with. (fixme: need to
specify sugar versions somewhere. Obviously we start with 1.)" ****
**** if this is incorrect, please, PLEASE (!!) remove it from the f$#
%ing bit rot wiki!
Michael Stone wrote:
> On Wed, Jul 16, 2008 at 09:10:56AM -0400, Greg Smith wrote:
>> Who can gather the consensus and take responsibility for updating the
>> wiki if needed?
> No one can, yet, because there's a real argument going on between the
> people who have to live with the versioning scheme on the infrastructure
> and security side and the people who want to use it in the UI.
> In particular, there are non-trivial security issues with identifying
> activities internally with _anything_ spoofable - i.e. with any
> identifier that an activity can 'claim' without reference to some more
> primitive sense of identity (e.g. a cryptographic manifest).
> Consequently, as I have claimed on the several other occasions when this
> discussion has come up, we are _not_ going to decide on an activity
> naming and versioning scheme without having written down our use cases
> and checked that the proposed design satisfies them.
> What _should_ be happening in this thread is the collection of use
> For a "small" selection of the issues involved, please refer to
More information about the Devel