ubuntu-phone team mailing list archive

[Dimitri John Ledkov <xnox@xxxxxxxxxx>]

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?

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)
-- 
Regards,

Dimitri.