ubuntu-phone team mailing list archive

[Nekhelesh Ramananthan <krnekhelesh@xxxxxxxxx>]

On Fri, Oct 24, 2014 at 5:34 PM, Sergio Schvezov <
sergio.schvezov@xxxxxxxxxxxxx> wrote:

> On viernes 24 de octubre de 2014 10h'03:01 EDT, Nekhelesh Ramananthan
> wrote:
>
>> Hi Lukasz,
>> I am curious as to how core apps which are currently distributed as click
>> packages in the ubuntu touch store can accommodate the process you
>> described. For instance in the clock app, we currently have trunk where all
>> the development (features and bug fixes) go into. While it is easy to have
>> a separate branch for vivid (trunk) and ubuntu-rtm (14.09), the ubuntu
>> touch store does not allow for two click packages of the same application.
>> So If I do make use of new Ubuntu SDK features in vivid, then I am
>> essentially dropping support for ubuntu-rtm since the click package
>> produced will have a higher framework than what will be shipped with the bq
>> and meizu devices.
>>
>> I have brought this issue earlier, but it didn't seem critical at the
>> time. But now that we have a so called stable series (ubuntu-rtm) and a
>> development series (vivid) both of which needs to be supported in parallel,
>> I am not sure how to proceed.
>>
>
> click packages, to this date, only care about the "framework" it supports.
>

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.