On Tue, Jul 28, 2009 at 1:39 AM, Daniel Drake<d...@laptop.org> wrote:
> 2009/7/28 Aleksey Lim <alsr...@member.fsf.org>:
>> The problems that 0.84 has in case of activity versions are:
>>
>> * it can't upgrade activities if they were pre-installed from
>>  native packages; it makes process of upgrading activities
>>  from .xo impossible
>
> In reality Sugar's message is confusing here and I don't think any
> distributor will mix-and-match the two ways of installing activities.
> (either they'll use distro packages and disable .xo, or they will
> exclusively use .xo e.g. OLPC).

This grows into a somewhat complicated issue for mozilla addons.  It
is rather common for distributions to mix and match the method for
installing addon.  Distros tend to repackage addons when they want to
add branding or add a bug fix.

david

> This is a larger problem and I don't think yours is a solution, since
> it will result in wasted disk space and we still end up with the
> confusion of how activities can be installed and which one is being
> used.
>
>> * sugar can have only one activity version installed at the same
>>  time i.e. it could be useful to have several versions
>>  simultaneously e.g. to start proper version when join request
>>  arrived(activity version of arrived request could be different
>>  to installed version)
>
> I think this calls for wider discussion. Having multiple versions of
> the same activity installed sounds silly. Instead, activity designers
> should be encouraged to strongly avoid making backwards-incompatible
> protocol changes, just like the principles of any other software
> designer. Once everything is compatible, this problem goes away. Sugar
> should continue to make no promises about interoperability between
> different major releases (e.g. no promises about 0.82 talking to 0.84)
> and hence if it is necessary, activity developers are allowed to break
> compatibility once every 6 months, which should be more than enough.
>
> Finally, I personally don't like the idea of having activities (as in
> applications) in the journal. The journal is for recording what the
> user has done.
>
> Daniel
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Reply via email to