ubuntu-phone team mailing list archive

[Sergio Schvezov <sergio.schvezov@xxxxxxxxxxxxx>]

On Tue, Oct 28, 2014 at 3:48 PM, Nekhelesh Ramananthan <
krnekhelesh@xxxxxxxxx> wrote:

> 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?
>

This may help a bit (for the QA side):
Silos for click are coming to a server near you.


The rest I defer to beuno and/or pmcgowan