On Tue, Oct 28, 2014 at 2:48 PM, Nekhelesh Ramananthan <[email protected]> wrote: > 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.
Right. You should consider the version of you app the uses ubuntu-sdk-14.10 as the released version. That's what's public, that's what you'll get ratings & reviews on, and what the public in general will download and judge. > 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. Right. The plan is to build a feature into the store that allows to beta test an app. That would be opt-in for users, would be programatically accessible from things like CI, and would allow us to decide if a specific image pulls from the public version or the beta one. It would also extend beyond this, where any user who installs a development version can opt-in and follow the beta programme, giving you more visibility as you develop. Remember that the frameworks themselves you'd be basing on are development frameworks that can be broken at any time. > 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. Well, the reality is we get to introduce frameworks at will, we don't need to tie them to releases. That means we can introduce them more often or even less, depending on how our ecosystem evolves. It's important for us to not fragment our ecosystem, so we want to make sure the store, one of the guardians of how the ecosystem can evolve, ensures that the default path is to support one version of the OS, and one in-development, because that's what we're trying to build. > 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? Yes, a beta channel is the short answer :) I don't have a schedule for you yet, but it's important as we start to move faster and roll over releases and framework versions combined with shipped devices. Hope this makes sense! -- Martin -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
