← Back to team overview

ubuntu-phone team mailing list archive

Re: ANNOUNCEMENT: Vivid and ubuntu-rtm landing procedures

 

On Sun, 2014-10-26 at 23:55 -0400, Robert Schroll wrote:
> I've asked this before [1], but I've yet to receive a satisfactory 
> response: What about the desktop?  The killer feature of this new SDK, 
> we've been told, is that it'll work on the phone and the desktop 
> equally well.  So,

Moving toward convergence of all platforms is an on-going process. We
aren't there yet, but we're moving in the right direction to get there.

> 1) Is the desktop moving to a rolling release?  As an LTS-to-LTS kinda 
> guy, I certainly hope not.

For the convergence plan to work, I don't see it happening any other
way. We're still probably a year or so away from that happening, but
having all platforms converged and sharing the code, they will all also
need to be on the same release plan. That means system-image updates for
the base Ubuntu system on any hardware, and confined apps in click
packages that are built on top of framework versions.

> 2) Will the SDK be kept up to date via backports or PPAs on the 
> desktop?  So far, it hasn't happened.

The SDK is up to date via the SDK team's PPA. However, the SDK being up
to date, and the runtimes being up to date, are not the same thing. The
SDK builds in chroots. If you require 14.10 frameworks, then building
and running on 14.04 isn't going to work. This is no different than it
has ever been.

> 3) Will the SDK be completely backwards compatible? Obviously not -- 
> the point of versioning it is to add features.

It will be backward compat until deprecated features get removed, as far
as I understand. This has always been the case in Ubuntu. The store
scope already only filters the results to only show packages which use
frameworks that are installed on the system. If you use a 14.04
framework, and it doesn't work on 14.10 even though the system says the
framework is available, then I'd say that is a bug in the system and we
should get it fixed asap.

> 4) Will there be some way for apps to react to the framework they find 
> themselves running under?  So far I've heard "no".

No. You should build your app using the APIs in the oldest version you
wish to support.

> Without any of these, we app authors have to (a) target a framework old 
> enough to be on the oldest desktop we're interested (likely a LTS, and 
> do you really want people using Ubuntu.Components 0.1 until 2016?) and 
> (b) hope that the old frameworks are completely forward-compatible on 
> newer images (they aren't).  Already, I find that the only way to get 
> my app to run both on a current device and the 14.04 desktop is to do 
> Loader hacks to detect which framework is supported [2].  It'd be much 
> better if there were a straight-forward way to do this.

If you want to target an Ubuntu LTS release, then using the SDK is
probably not the beset solution at the moment. Not that it terribly
matters. Installing click packages and using Unity 8 on Ubuntu 14.04 is
not supported. The SDK's UI elements are built to target the phone and
tablet platforms with apps running maximized always, under confinement,
under Mir. Running those apps under Xorg may work, but it is not really
supported. Frameworks will never be forward compatible. If you use the
14.04 framework, your app won't automagically get new features only in
the 15.04 framework. Apps packaged as .debs have no idea about
frameworks. There's a reason the click store and software-center are
separate things, and we don't yet support the former on anything other
than the phone/tablet (ubuntu touch builds).

The UI elements in the SDK also present interaction problems on
traditional PC hardware, as they are designed for the phone and tablet.
If you want to target the SDK frameworks with your app, then it's best
to limit device targets to those the SDK targets as well. Running SDK
based apps on a PC is basically a tech preview at this point, and not
well supported. As we move toward convergence, get Mir working with
windowed applications, and get interaction issues with the SDK elements
worked out, this will of course improve.





References