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

[Marco Pesenti Gritti]

On Sat, Jul 12, 2008 at 1:43 PM, Morgan Collett
<morgan.collett at gmail.com> wrote:
> 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.

This sounds pretty good to me for Glucose at his current stage. Could
you put it on the SugarLabs wiki under DevelopmentTeam (making clear
it's under discussion)?

When the project is more mature I'd like to adopt something like the
GNOME ABI policy, but we are definitely not there yet.

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

Yeah, I think we can only really start from Update.1

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

For Glucose I'm happy to consider breaks from Update.1 as bugs.

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

Yeah, as I asked above let's start to document ABI policy in the wiki.
Violation of the policy will be considered very high priority
(blockers?) bugs.

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

As soon as we have a clear policy, activity authors will be able to
report ABI breakage. Then on a case by case base we can decide on the
"well behaved" aspect.

>> Any other suggestions on how to bound this test challenge appreciated!

SugarLabs will make sure that the activities included in Fructose will
continue to work. You can see a list of them here:

http://wiki.sugarlabs.org/go/ReleaseTeam/Roadmap#Fructose_Modules

For other activities it's really up to the author.

We should encourage the authors of activities that OLPC is interested
to "support", to get them included in Fructose. That way they will
follow a schedule which is compatible with the OLPC distribution one
and benefit from the community testing provided by SugarLabs.

Marco