On 13-12-16 11:05 AM, Dimitri John Ledkov wrote: > On 16 December 2013 15:27, Jamie Strandboge <[email protected]> wrote: >> On 12/16/2013 07:54 AM, Dimitri John Ledkov wrote: >>> On 16 December 2013 13:27, Martin Albisetti <[email protected]> wrote: >>>> On Mon, Dec 16, 2013 at 10:14 AM, Alan Pope <[email protected]> >>>> 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. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
