Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)

[Morgan Collett]

On Sat, Jul 12, 2008 at 00:56, Greg Smith <gregsmitholpc at gmail.com> wrote:
> Hi Guys,
>
> We should definitely have backward compatibility for activities!

In my opinion, there should be compatibility from one release to the
next. APIs should not break from release to release unless critically
necessary. If there is a new way of doing things which is better, the
old way should still work - but it should warn in the log files that a
deprecated API is being used.

We should announce API deprecations - and API breaks where necessary -
in advance of a new release (as well as release notes) so that
activity authors are well aware of what is happening. This is done for
Python releases, for example, giving people details on how to update
python code from one version to another.

Indefinite support of backwards compatibility certainly has been a
major cause of platforms deteriorating (I'm thinking of Windows here).

> That is, activities that used to work (maybe starting at 656) must
> continue to work. If a new release requires that all activity authors
> have to recode some of their work, that will be a major deterrent to
> working with us.

65x releases did not have Rainbow running, so activities could access
and write to places on the filesystem which are no longer possible.
For that reason we can only really focus on activities which already
run on Rainbow.

> Its also a deterrent to deployments upgrading, assuming they find out
> their activities are broken before they upgrade.
>
> I understand that we do not have backward compatibility in 8.2.0 as it
> currently stands.

My understanding is that we made no particular guarantees, and while
we did not intentionally break APIs, some things may have broken along
the way.

I think our development process should include some sort of
compatibility management - perhaps as I mentioned above with API
support between two consecutive releases - and this could be enforced
or monitored with some sort of test activity (or test suite) that uses
the various Sugar APIs and reports on failures.

> Can we bound the test problem by saying that all "well behaved"
> activities will continue to work?

Unfortunately I think our APIs are insufficiently documented (or have
been) so that even core activities are not guaranteed to be "well
behaved".

> If we can define "well behaved" and not test activities that meet that
> criteria it will save us a lot of test time.

I think a better criteria would be "responsive activity authors" who
make some kind of commitment to keep their activities up to date from
release to release. I don't think we should spend resources testing
arbitrary third party activities, but where we can maintain a
responsive developer community we can include them in the process.

> Any other suggestions on how to bound this test challenge appreciated!
>
> e.g. can we say that all activities not listed on this page:
> http://wiki.sugarlabs.org/go/ReleaseTeam/Releases/Sucrose/0.81.4 will
> work the same in 8.2.0 as they did in previous releases?

Not all activities were updated in Sucrose release 0.81.4 - some were
updated in previous Sucrose releases. The activities listed in
http://wiki.sugarlabs.org/go/Modules are ones where the maintainers
have agreed to use the Sucrose release cycle (and other conditions
listed in http://wiki.sugarlabs.org/go/ReleaseTeam#New_activities).
These are activities which the Sugar project lists as demo activities,
and may or may not coincide with OLPC's deployed activities (in the
long term, as other users of Sugar emerge) - but they are certainly
candidates for OLPC's use.

Thus I would say that activities *not* on that list are the ones that
are *not* guaranteed to work with 8.2.0, because the authors did not
step up and take an interest in the new release.

> In the future if some piece of core code will cause previously supported
> activities to no longer work, I hope we can discuss and accept or reject
> that in advance (sorry if I missed that debate on this round).

API breaks should be discussed during a development cycle as the need
for them emerges, hopefully as early as possible in the cycle so there
are no surprises.

> In the worst case we have to test as many activities as possible but its
> much better to ensure API changes are not breaking things from the OS level.
>
> On the other hand, newer activities can require a newer OS. That can be
> handled if we have good activity documentation on the download and
> activity pages.

Yes. You've been talking about running old activities on a new release
- I would include new versions of activities here which may require a
newer OS/release.

Perhaps we should change the activity service name (e.g.
org.laptop.Chat) when an activity is updated in such a way that it can
no longer run on old releases. Perhaps that should also be done when a
newer version of an activity can no longer collaborate with an older
version.

> Sounds like we have a big activity test challenge ahead for 8.2.0...
>
> BTW is this the full list of all known activities?
> http://wiki.laptop.org/go/Activities
>
> Let's talk more about this on the Tuesday call.
>
> Thanks,
>
> Greg S

Regards
Morgan