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