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 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

> * 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.

Sugar-devel mailing list

Reply via email to