Fenix: FNX-475 ⁃ Setup the Beta application on the Play Store

[ghost]

Since the beta will be a separate application, we will need to set it up on the GPS. This ticket covers both technically but also assets and meta data. We can split it up if that is better.

Meta Bug on Bugzilla - https://bugzilla.mozilla.org/show_bug.cgi?id=1545401

[mitchhentges]

The bugzilla ticket associated with acquiring credentials for this is here: https://bugzilla.mozilla.org/show_bug.cgi?id=1545404

[ekager]

Can this be closed or are we still tracking work here?

[mitchhentges]

I'd prefer to close this once the beta application goes live, which it hasn't yet :)

[sblatz]

@mitchhentges are you owning this? If so please assign yourself so we can track the progress of this ticket :)

[mitchhentges]

I can own this, but be advised that I'm not actively working on it (my understanding is that we're not deploying the beta for a while yet). Let me know when we want to get moving on the beta again :)

[Edu4rdSHL]

Definitively will be good to have a beta program in the Play Store, it gives more facilities to users that want to test the latest beta releases instead that checking in Github if there are available releases, downloading and installing it manually.

[mitchhentges]

I don't believe we have any beta releases yet. There's some rc ones, but if they haven't been made public, it's because the Fenix team is testing them internally. I don't believe that they would be published to a "beta" track.

Once we have "beta" releases, the beta track on Google Play will be set up.

FWIW, for users that want to test the latest Fenix features, they can use the Fenix Nightly releases, which are super-bleeding-edge :smile:

[Edu4rdSHL]

Where are the Fenix Nightly releases? Will be good to put that in the README.

[mitchhentges]

We're setting up a more official nightly soon, but we have a "private" nightly that's _definitely totally_ a secret that you can access by joining our fenix-nightly Google Group.

[Edu4rdSHL]

Thanks, I have sent the request.

Edit:
I have setup the nightly builds, thanks.

[liuche]

Here are my thoughts on the Beta.

Purpose: (temporary?) train model, for wider-spread testing (both by users and QA)

• stable Beta channel for users to check out new features 2+ weeks early, and give early feedback
• channel for QA to do any additional testing before apps go to FP Release

Workflow for how releases will be published:
Release Tuesday:

• Builds will be published to Beta based on a new version branch cut at the end of every sprint. (e.g. 1.7-RC1)
• Previous version branch will be published to release (e.g. 1.6. @mitchhentges, I'm not sure what this should look like, and if this is something we can automate)

If any fixes need to go into the Beta, we'll land those on master, uplift them to Beta, and publish a new Beta (e.g. 1.7-RC2).

Nightly will still be published every day to the Nightly channel (the new one, once we get that going).

Let me know if this seems reasonable, @mitchhentges ! Also, let me know if we could run the first Beta release on Tuesday 8/20.

[mitchhentges]

Makes sense! I have some other fenix work that I'd like to resolve first, then I can take a look at this

[liuche]

Had a quick end-to-end conversation I had w/ Mitch that I'll summarize here.

Current Nightly: publishes to internal track of Release App w/ users from the FP mailing list
TODO: switch publishing destination to Nightly App (in the beta track, so it says "Experimental")

Current Beta: existing releng work that can be used with the beta versioning semantics for tagging release through Github (v1.0.0-beta.0)
TODO: hook this up to the Beta App when it's ready. Discuss whether we want someone to manually promote from internal track, or publish directly to beta track.

Release promotion TODO: use existing process to publish.
No plans for automation to auto-promote from Beta App.

[mitchhentges]

I discussed directly with Chenxia, the beta automation will publish to the internal track, and a human will manually promote from there.

[liuche]

For the releng process, this means we'll have to add some more steps, namely:

• Make a beta build (following the same steps as Release)
• Make a release build from the previous release branch (tagging the previous beta branch with the release tag)
• Filing Bugzilla to launch beta (in the future, it's possible we might want to automate that)
• Filing Bugzilla to launch release
• Uplift any changes to beta and re-tag (for release blockers, or bugfixes) and get QA signoff

What this might change for QA is that, as long as we don't have any bugfixes that need to be uplifted directly to the upcoming release:

• There doesn't need to be a QA signoff for release - that will happen during the beta bake period
• QA will need to test any beta uplifts

Open question: when do we cut a beta branch? We probably still won't want to cut on Friday.

However, we're planning on trying out the beta for 3.1, which won't be until the sprint starting 11/11.

[liuche]

This channel is live, with #109.