ext Dave Neary <dne...@maemo.org> writes: > Then a new version of the SDK comes out, which is not backwards > compatible. A number of potentially bad things can happen:
I agree with your points in general, but I want to qualify them a bit. There are two issues: - I think it is very important to be able to release new OS versions and new SDK versions that add APIs. - I also think that it is important to be able to remove APIs in a controlled way, but much less so than being able to add APIs, and we can leave that for later, once we have figured out how to add APIs. > 1. New uploads get compiled with the new SDK, and get downloaded onto > phones with the old OS, where they don't work. This is one kind of bug: the new SDK has added APIs compared to the old API, and applications that use the new SDK wont run on OS versions that doesn't have that API. Some will not work, and some will not even install, but most of them should install and work. New uploads should only not install or work (by necessity) when they actually use the added API. If they don't use any of the added API, they should install and work with the old versions of the OS. Our SDKs are not very good at producing the necessary dependency information for this (i.e., our library packages don't use dpkg-gensymbols, and we do not maintain the -V option of dh_makeshlibs), and as a result, almost all packages will erroneously refuse to install into a old OS when they have been compiled in a new SDK. This is a bug in the SDK (i.e., in the tools and in the packages), it is unfortunately _not_ trivial to fix, but it is very worthwhile to fix it. (RPM does it differently, so maybe this isn't actually worthwhile to fix, but let's ignore that for now...) We should at least check each new SDK release for undesired changes in the shlibs files. > 2. Developers working with the old SDK upload applications which don't > even build with the new SDK This is a different kind of bug: this will happen when the new SDK has removed APIs compared to the old SDK. It's a bug in the SDK and should be fixed. > 3. To mitigate 2, we decide that all Extras apps need to be recompiled > with the new SDK, [...] That would be foolish, and we should not do it. As you say, we would run into the SDK bug responsible for category 1 above. We can and should avoid that by not recompiling applications just because the SDK has been updated. Instead, before accepting a SDK release, we should check whether it can still compile all the Extras apps. If not, we have found a bug, either in the SDK or in the Extras app. That bugs needs to be fixed, and there wont be many of these. > All of these push inconvenience to the phone user & application > developer - all unnecessary overhead, especially if the APIs haven't > changed and there are issues with run-time library versions (as we saw > with PR 1.0 to 1.1). Agreed. > The only way to avoid badness when upgrading the SDK in a > not-backwards-compatible way is to have scratchbox, every developer > copy of the SDK, and the N900 firmware all upgrade at the same time. That's fortunately not the only way, although the way outlines above isn't particularily easy. The established GNU/Linux upstreams and distributions have this pretty much under control. _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
