ubuntu-phone team mailing list archive

[Nekhelesh Ramananthan <krnekhelesh@xxxxxxxxx>]

On Fri, Oct 24, 2014 at 6:23 PM, Rodney Dawes <rodney.dawes@xxxxxxxxxxxxx>
wrote:

> On Fri, 2014-10-24 at 18:10 +0200, Nekhelesh Ramananthan wrote:
>
>
> > I know and agree, but that is a limitation which will prevent me from
> > improving the clock app further. Let me provide an example to explain
> > this better. With 15.04 development cycle open, the SDK developers are
> > planning to add new listitem components which are supposed to bring
> > about performance improvements and also customization options to the
> > app developer. However when this lands, the frameworks version will be
> > bumped to ubuntu-sdk-15.04-qml-dev. Clock app at the moment uses
> > ubuntu-sdk-14.10. Now if I bump clock app's framework version, then
> > any bug fixes that I push to clock app trunk cannot be backported to
> > rtm devices since they ship with ubuntu-sdk-14.10. The new listitems
> > are absolutely critical since they will allow me to remove a lot of
> > custom code that I have to maintain and rely on official well tested
> > upstream sdk components.
>
> I think the only way to fix that is to somehow enable conditional
> runtime dependence on the frameworks. If your target is RTM, you
> shouldn't be developing against a newer version of Ubuntu than RTM is.
> You can only use frameworks available in RTM for core apps, I think.
>
> You will have to wait until RTM is done and we move to a Vivid based
> image for future OTA updates for customers, before being able to use
> newer frameworks.
>
> You can create a branch to develop features that depend on new API in,
> and then merge it back to trunk when those features are usable in a
> supported image. But I don't see any way for supporting multiple
> different framework versions in an app, on a system that is designed to
> be a single rolling release.
>
>
>

So let me summarise what I intend to do below and please let me know if I
am following the correct approach. As I understand, BQ and Meizu will ship
with the stable framework *ubuntu-sdk-14.10*. So I will have a clock
rtm-branch in launchpad where I will push out only bug fixes and not
introduce new features (since they most likely would require a newer sdk
framework). There will be another clock vivid-branch in launchpad which is
where all new development stuff like new features, bug fixes, upgraded sdk
framework will be done.

Since the touch store will only accept one click package per application *and
*considering that we need to obviously support the RTM devices, click
packages will be built from the clock rtm-branch and pushed to the store.

We will have to wait for the *ubuntu-sdk-15.04* to become stable and pushed
to the BQ and Meizu phones which will happen when Vivid gets released (6
months from now) at which point, we can start generating click packaging
from the clock vivid-branch and push that to the store.

The only question that remains is how can we get the QA team to dogfood the
clock vivid-branch until vivid is released 6 months from now? This is not
an issue for other applications like gallery, dialer, address book since
they are distributed as debs at the moment and hence can have multiple
packages targeting both their rtm and vivid branches simultaneously in the
respective rtm and vivid phone images. Should the core apps perhaps switch
to debian packaging to overcome this limitation *until *the touch store has
support for stable and beta channels like Android does?

Cheers,
Nekhelesh