[maemo-developers] Backwards compatibility broken PR1.1 SDK

[From: Graham Cobb]

On Monday 18 January 2010 21:08:33 Niels Breet wrote:
> I've been discussing this issue with some people before as hypothetical
> case, but now it seems that we run into it: Compiling an application
> against the PR1.1 SDK creates packages which can not be installed on
> earlier firmware releases.

The problem isn't really new: we have had it with all Maemo releases in the 
past.  For versions 1-3 it was something the developer had to handle 
themselves, for version 4 it impinged on the autobuilder and is one reason we 
insisted on a new name ("Diablo") for the release after Chinook, so it was 
easy to build different versions (although, in fact, binaries built on 
Chinook normally run perfectly well on Diablo).

For GPE I still build against Maemo 2, Maemo 3 and Maemo 4 and, in each case, 
I use the SDK from the .0 release to build binaries which will run on any .* 
release.

> The autobuilder uses the repository.maemo.org repository, so it
> automatically uses newer packages when they are available.

A particular autobuilder queue name should always use a fixed SDK release, 
with contents which never change.  That is what the "queue name" really 
means, in my opinion.

> 1: Only compile against the original SDK.
>    This prevents new features from ever be available to developers,
>    but should work until there is real API/ABI breakage in a new
>    firmware.

This should be the answer for "small" releases (like we have here).  Just in 
case anyone is confused, in most cases building against an old library does 
**not** mean that running with a new version is prevented: so bug fixes in 
newer releases of libraries work fine.  The only thing this option prevents 
is using a new **feature** (in particular, a new function call) in the new 
library which was not in the old library.

> 2: Use version specific repositories
>    This needs Application Manager support as we need to fetch from a
>    separate repository every time. Also requires us to build against
>    every sdk version known to man.

For "larger" releases (in particular, ones with new features in libraries 
which developers may want to use), the release should be given a new name and 
a new repository and a new autobuilder queue should be created.  If backwards 
compatability is expected, it would be feasible to populate the new 
repositories (extras, extra-testing and extras-devel) by just copying the 
packages from the previous release but new versions of the packages could be 
built to use the updated libraries if they wished.

> 3: Depend on >= mp-fremantle-generic-pr | maemo-version
>    We would need a hack in the autobuilder to add depends to pr and
>    maemo version. This way a user needs to upgrade to at least the
>    required firmware image. I think this will make it easier for an
>    end-user to understand what is happening.

I don't like this.  We should not have an application forcing a maemo software 
upgrade.  Different people will have very different tolerance to doing 
software upgrades (most of us developers and power users are keen to try new 
releases, but most ordinary users will resists as long as possible).

It certainly can't be the case that just building after the new release has 
been shipped means your users have to upgrade.  If I have thousands of users, 
I need to be able to ship new releases to them without forcing an upgrade.  
Don't forget that upgrades are not even available to all users at the same 
time (today we have the Vodafone problem, which will only get worse in future 
with different operator versions and different country versions available at 
different times).

I do think there may be an option 1.5: create multiple autobuilder queues 
which feed the same repository but build against different SDK releases.  For 
example, a "fremantle" queue which builds against the base release (for 
ever), and a "fremantle-pr1.1" queue which builds against the new SDK (for 
ever), but both populate the same repository (extras-devel fremantle).  That 
would allow the applciation developer to decide which users they are willing 
to support.  If the application supports all fremantle users it submits to 
the fremantle queue.  But if it uses a new feature (or even an important bug 
fix) from the pr1.1 release the maintainer could submit it to the 
fremantle-pr1.1 queue.

If we did this, I wouldn't object to automatically adding a dependency on the 
device software version, as long as it is worked out from which queue you 
submit to.

Graham