On Tue, Oct 28, 2014 at 3:48 PM, Nekhelesh Ramananthan < [email protected]> wrote:
> On Fri, Oct 24, 2014 at 6:23 PM, Rodney Dawes <[email protected]> > 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
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
