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

Sat Jul 12 12:39:50 EDT 2008

On 7/12/08, 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.

Problems arise independently of API when libraries not part of the
base system are used.  For example, I have an activity that uses
goocanvas and the glibmm libaries, which I package in the activity
bundle.  I tried first using glibmm from F9, but it didn't work on
F7-based builds.  I then substituted glibmm from F7, and it works on
656, 703/8, and all the recent joyrides.

I don't know the best way to handle this generally, I suppose it is up
to individual activity owners to make sure their stuff works all over.

bobby

>  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
>
> _______________________________________________
>  Devel mailing list
>  Devel at lists.laptop.org
>  http://lists.laptop.org/listinfo/devel
>