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

[Greg Smith]

Hi All,

Responding to all in one pass.

 From Scott -
> The general solution to this problem is trac #4951, the activity
> updater, which I've landed recently.  Trac #7495 says that the first
> boot after an upgrade should open the activity updater, so that a
> version of the activity compatible with the new OS can be installed if
> necessary.  The activity update protocol understands simple base OS
> dependencies, so that you can specify a different version for 8.1 and
> 8.2 (for example).  The [[Activity_bundles]] wiki page documents the
> update_url tag.

GS - Sounds good but it still requires all activity developers to update
their activities which I think is the central problem. Also, we still
need to warn users in advance, especially if they upgrade via USB.
Definitely will help so let's do it if its not too much work.

 From Michael -
2 -
> 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

GS - How certain are these and is there any documentation of them or
what activity changes they will require? We should agree that they are
must have items worth requiring activity upgrade before doing them and we
should document what it will cost activity developers if we do.

> As above - it is our responsibility, when making breaking changes, to
> help carry our downstream partners along with us.
and related comments

GS - Does anyone have the contact info for the developers of all the
currently available activities? Can we document the changes they need to
make in 8.2.0 and contact them? Let's also ask them what they think
about us requiring they rewrite in each release.

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

GS - I'm asking if we can tell developers "here are the things you can
do which will be safe". That is, make some kind of promise of backward
compatibility for some subset of all functionality.

>  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

GS - Will read Monday, thanks.

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

GS - I thought it was precise :-) and I meant "not". I want to know if
we can promise that *any* activities will continue to work. I hoped that
these Sugar activities are the only ones using some APIs (e.g.
collaboration) and therefore the only ones susceptible to breakage.


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

GS - I'm saying let's make sure to discuss and agree before making any
API changes that might break activities.

> Tuesday call?
> 

GS - Sorry I meant Tuesday software IRC/Gabble meeting. We are on for
Tuesday and Wed. again this week at the same times, right?

RE: Marco's comments.

GS - Thanks! Can you start adding the names of all activities that we
know should/will work to the Release notes too?

How does someone know what version they have of an activity in Fructose
or Glucose?

Its helpful to claim "backward compatible" from Update.1. However, I
believe many people will be upgrading from 656 too. Maybe we have to
say: "upgrade all your activities" in that case?

**********
A few more questions on this:
- Leaving aside how its done technically, I believe that Linux 
distributions are fully backward compatible. That is, you can go to the 
latest supported Distribution and leave your Firefox (or any 
application) on its older release and it will still work fine. Let me 
know if that is not correct. I think that is what we need to strive for, 
eventually.

- Black box testing of all activities is not feasible unless the
authors do it themselves. Can we grep all the activity source code for
the functions (or objects or whatever) that have changed and determine
which activities might break? I haven't learned much about activity 
creation and bundling yet so pardon my ignorance if this is a naive 
question.

Until we get a better grip on "downstream" relationships with activity
authors I think the only short term answer is better documentation.

Can someone put up a wiki page that explains what has changed and tells
activity authors what they need to check in their code to determine if
they are still compatible?

Bobby,

Are you ready to upgrade your activity every 6 months? Do you promise?
:-) Do you know what to do in this release?

**********
Sorry for the long thread but I'm worried. If any significant activities 
fail on upgrade, users will hit the roof. Users don't know the 
difference between the OS and the activities (not sure I do either :-). 
They just know something used to work and after we told them to upgrade 
it doesn't.

Imagine someone walking 20 hours through the jungles of Peru with a
USB stick. Upgrading a remote school then finding out they can't save in 
Write or TamTam. They can downgrade (kudos to whoever built that!) but 
he has to walk 40 more hours now to fix it. If he read the release notes 
and there was no mention of this, that will be one angry technician!

Hopefully I'm being too conservative and 8.2.0 will go easy so we have
more time to come up with a plan...

Thanks,

Greg S