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