ubuntu-phone team mailing list archive

[Martin Albisetti <argentina@xxxxxxxxx>]

On Tue, Oct 28, 2014 at 2:48 PM, Nekhelesh Ramananthan
<krnekhelesh@xxxxxxxxx> 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