ubuntu-phone team mailing list archive

[James Henstridge <james.henstridge@xxxxxxxxxxxxx>]

On 31 July 2015 at 05:34, Martin Albisetti <argentina@xxxxxxxxx> wrote:
>
> On Jul 30, 2015 5:35 PM, "Alberto Mardegan" <alberto.mardegan@xxxxxxxxxxxxx>
> wrote:
>>
>> On 07/30/2015 11:09 PM, Martin Albisetti wrote:
>> > I'm assuming this changes needs to be paired with:
>> >
>> > - Dropping all frameworks as supported from that image once this lands
>> > - Introducing a new framework
>>
>> Is (or will it be) possible to upload to the store more than one version
>> of one app, if these versions require different frameworks?
>>
>> If so, the transition wouldn't be as painful for app developers.
>
> That isn't planned, no. The main reason being we said we would keep
> backwards compatibility aggressively, and we would keep our phone user base
> on the same, updated OS version to avoid fragmentation.
> This GCC change seems to break on that, I was surprised by it, but maybe
> there's a plan on how to keep backwards compatibility instead?

One possible solution that was mentioned when we discussed this
compatibility problem in the context of scopes was to have a vivid LXC
container on the phone that contained all the old libraries.  Scopes
using the old framework versions could be detected at run time or
install time and run in this environment.  Provided things are
compatible at the interprocess communication level, this should be
transparent to the user.  The same model might work as a compatibility
mode for apps too.

It does have its downsides though:

* The LXC container is going to take up extra storage, reducing the
amount available to the user.

* If you've got both new and old ABI apps running, then there will be
two copies of the library in memory

* We'd need to support the packages in the vivid LXC for as long as we
provided the compat layer.

* If we made any incompatible changes to any IPC protocols or formats
for data stored in the user's home directory, we'd need to backport
equivalent changes to the vivid versions of those packages.

* All these problems multiply if we introduce yet another incompatible
framework version.

So while it might be a workable approach to providing a transition
period, it isn't the kind of thing we'd want to keep supporting until
the end of time.  So if we ever have any devices stuck on vivid, we
would need the ability to provide two package versions from the store
to different devices.

Of course, if we rebase on snappy fast enough, perhaps we'd just get
people to provide the package for old phones as a click and the one
for new phones as a snap.

James.