On 7/12/08, Morgan Collett <[EMAIL PROTECTED]> wrote: > On Sat, Jul 12, 2008 at 00:56, Greg Smith <[EMAIL PROTECTED]> 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@lists.laptop.org > http://lists.laptop.org/listinfo/devel > _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel