On 16 December 2013 15:27, Jamie Strandboge <ja...@canonical.com> wrote: > On 12/16/2013 07:54 AM, Dimitri John Ledkov wrote: >> On 16 December 2013 13:27, Martin Albisetti <argent...@gmail.com> wrote: >>> On Mon, Dec 16, 2013 at 10:14 AM, Alan Pope <alan.p...@canonical.com> 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. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
