ubuntu-phone team mailing list archive

[Marc Deslauriers <marc.deslauriers@xxxxxxxxxxxxx>]

On 13-12-16 11:05 AM, Dimitri John Ledkov wrote:
> On 16 December 2013 15:27, Jamie Strandboge <jamie@xxxxxxxxxxxxx> wrote:
>> On 12/16/2013 07:54 AM, Dimitri John Ledkov wrote:
>>> On 16 December 2013 13:27, Martin Albisetti <argentina@xxxxxxxxx> wrote:
>>>> On Mon, Dec 16, 2013 at 10:14 AM, Alan Pope <alan.pope@xxxxxxxxxxxxx> wrote:
>>>>>
>>>>>
>>>>> We have core apps and 3rd party apps in the store. Currently each app
>>>>> in the store has one published version and that has ubuntu-sdk-13.10
>>>>> defined as the framework in the manifest.json. Related, as I
>>>>> understand it we have a plan to switch to ubuntu-sdk-14.04 at some
>>>>> point in this cycle. Do we use this point in the cycle to switch the
>>>>> apps to depend on the 14.04 framework, making those versions
>>>>> un-installable on ubuntu-sdk-13.10 based images?
>>>>>
>>>>> We _could_ maintain two branches of each app to be installable on
>>>>> pre-Qt5.2 and post-Qt5.2 - or ubuntu-sdk-13.10 & ubuntu-sdk-14.04, but
>>>>> can we deliver both to users simultaneously from the store? Does the
>>>>> store (and indeed the Application scope) support multiple different
>>>>> versions of the same app which are shown to different users depending
>>>>> upon SDK framework level?
>>>>>
>>>>> If the store and Apps scope do _not_ support this, when will they, and
>>>>> what's the plan for implementation, or is there some other magic I'm
>>>>> not seeing?
>>>>
>>>> The current situation is that the store supports one version per app,
>>>> and one version only.
>>>> While we could adapt it to support multiple ones, I think given the
>>>> way we've built our platform, easy and reliably updates to the core
>>>> OS, I think it would be wise for us to stick with one version only.
>>>> It would reduce the maintenance on developers and keep their focus
>>>> laser-sharp on the current platform, as well as having an incentive to
>>>> keep the experience nice and consistent with the platform rather than
>>>> let it bit-rot over time.
>>>>
>>>> IIRC, the scope will send the SDK version it's running and the server
>>>> will filter apps based on it (apps can define multiple supported
>>>> versions). Roberto can confirm.
>>>
>>> I am a developer. Due to binary incompatibility between
>>> framework-13.10 and framework-14.04 and differences in the Qt, I need
>>> to upload 4 clicks for a version of the application:
>>>
>>> * armhf for framework 13.10
>>> * armhf for framework 14.04
>>> * i386 for framework 13.10
>>> * i386 for framework 14.04
>>>
>>> Are you expecting for me to ship 4 binaries inside a single click,
>>> when only one of them will be executed on the client machine and the
>>> rest are unneeded cruft? If that is the case, my application size is
>>> balooned artificially 4x, and thus is pushed above a threshold one
>>> would choose to download over 3G for example or worse not install my
>>> app at all.
>>>
>>> What's the app developer story / plan here?
>>>
>>> I thought we will support one version of the app per ( framework X
>>> arch ) combinations.
>>>
>> Fat packages are being implemented for shipping multiple binaries for different
>> architectures in a single click package and these will be per version (which
>> should cut your example uploads above in half). I think expanding fat packages
>> to also support multiple frameworks is a mistake-- it adds a lot of complexity
>> (not least of which is how to apply security policy) and I think the benefit is
>> negligible-- apps will almost certainly not be expected to work across different
>> frameworks which suggests using different versions and if your app happens to
>> work fully with the earlier supported framework, just pick that framework rather
>> than using two (aiui, multiple frameworks will be shipped on the device).
> 
> Sounds good. Fat (as in arches) binaries should be actually
> in-practice small amount of the click size, with graphical assets /
> non-arch specific files taking the most of the application size.
> 
> How feasible do you think it is to ship a single framework at the time
> on the phone?

Ouch, I really hope we are going to maintain backwards compatibility. As a
developer, I hope I'll be able to ship a version of my app and not have to
necessarily adapt it all the time to arbitrary API churn.

> 
> E.g. sure compiled apps need a recompile, but I'd hope most
> "webapp-launchers" and "simple qml apps" can be bumped to next
> framework automatically, server-side at the store, without developer
> re-upload. [*]
> 
> [*] e.g. subject to automated ABI/API compatibility checking, running
> a basic autopilot test (open, close, put to background, put to
> foreground, whilst not generating crashes)
> 

We don't want to modify packages that are uploaded in order to preserve chain of
trust and accountability, so I'd say this isn't something we should be doing.

Marc.