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

[Michael Stone]

On Fri, Jul 11, 2008 at 06:56:35PM -0400, Greg Smith wrote:
> We should definitely have backward compatibility for activities!

Your desire to maintain backwards compatibility for activities is a
worthy goal but you need to be aware that there remain several areas in
which we will likely break compatibility in order to carry on further
development, both at the system and activity levels.

Off the top of my head:

  Activity toolbars
  Bitfrost protections
  Power-management work
  Datastore APIs
  Collaboration APIs
  APIs which hamstring our software on other distributions

In each of these cases, we may have the ability to gradually deprecate
old APIs by installing compatibility layers which implement them on top
of new primitives. However, we will be well advised to carefully weigh
the cost of maintaining these compatibility layers versus organizing the
labor, as a community, necessary to port all the activities we can find
to the new APIs.

Michael


A blow-by-blow:

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

In my opinion, we will simply have to include the cost of updating
activities in our estimates of the cost required to deliver features
which require API changes. 

> Its also a deterrent to deployments upgrading, assuming they find out 
> their activities are broken before they upgrade.

As above - it is our responsibility, when making breaking changes, to
help carry our downstream partners along with us. It is also our
responsibility to make breaking changes whenever doing so will improve
the overall capability of children working with our software to learn.

> I understand that we do not have backward compatibility in 8.2.0 as it 
> currently stands.

We mainly have bugs in 8.2.0. When we fix the bugs, we expect that we
will have 'pretty good' compatibility at the API level. Obviously, there
will be less compatibility at the UI level.

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

Not really. What we _can_ do is to keep really good records of what
activities are around and to invest in automated test facilities like
tinderbox and sugarbot which might permit us to measure our
compatibility status at an affordable cost.

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

As hinted above, I do not believe that we can spare activities from API
breakage. At best we can somewhat increase the amount of time in which
it is possible run software based on deprecated assumptions.

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

Titus Brown has written some persuasive arguments at

  http://ivory.idyll.org/blog/mar-08/software-quality-death-spiral.html
  http://ivory.idyll.org/blog/mar-08/pycon-08-thoughts.html
  http://ivory.idyll.org/blog/mar-08/peekaboo-and-screencasts.html

that I commend to your attention.

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

Your statement is too ambiguous to safely promise. Can you be more
precise about what you actually want to promise?

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

Again, please say more about what you're thinking of.

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

It's not prima facie "much better" to ensure compatibility AT THE COST
of leaving critical features unimplemented. As with all things, we'll
need to discuss it on a case-by-case basis.

> Let's talk more about this on the Tuesday call.

Tuesday call?