ubuntu-phone team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

On 12/16/2013 07:27 AM, Martin Albisetti 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.
> 
One thing to keep in mind when talking about all this is that the framework
consists of much more than the library versions used. This thread was brought up
in reference to Qt 5.0 moving to 5.2, but there will be new (and possibly
deprecated) non-Qt Ubuntu APIs between frameworks and the security permissions
will be different between frameworks. Apps need to be written for a particular
framework (we won't allow, for example, the apparmor 1.1 policy designed to be
used with ubuntu-framework-14.04 to be used with apps installed with the
ubuntu-framework-13.10). AIUI, the device itself will have more than one
framework available to support older apps using older frameworks to run on newer
devices.

To me it makes sense to support one version *per framework* per application.
This gives power to the developer to support what he/she wants[1]. Support the
latest framework only to always stay cutting edge-- fine, but you will likely
have fewer users. Support an earlier framework to get the most users with the
least effort-- fine, but you won't be able to use newer features. Support
multiple frameworks for the best of both worlds-- fine, but you'll have more
maintenance to do.

In addition to giving power to the developer, there is also the story about the
apps Canonical writes/supports. We want to ship webbrowser-app as click in the
store. What happens when Ubuntu is shipping on a device with one framework, then
6 months later it is shipping on a device with another framework. Both devices
with differing frameworks may be under support for some period of time[2]. What
happens when we need to perform a security update for webbrowser-app? If we
support only one version per app, we cannot support all of our users. If we
support one version per framework per app, we can.

Thanks

[1] I'm not saying that we should necessarily support all frameworks forever,
    but that decision can (and should) be taken separately from this discussion
[2] I realize this is gets at the question of what our support model will be
    going forward, but I don't think that the support model question has to be
    answered to answer the question of supporting one version per framework per
    app. It seems clear to me that at the very least there will be a period of
    overlap until the first device upgrades to the latest supported framework,
    and it would be a shame if our users on this earlier framework missed out
    on security fixes or emergency, high-impact bug fixes while still on a
    supported device

-- 
Jamie Strandboge                 http://www.ubuntu.com/

Attachment: signature.asc
Description: OpenPGP digital signature