Engine-Gecko: Create variants for "beta" and "nightly"

[pocmo]

Current state

Currently we build against GeckoView Nightlies. At some point we want to build against Release versions - so that we can ship stable products based on the engine component.

Problems

Even though we want to use release builds in shipping products, we still want to be able to use beta or nightly builds too:

• (A) We want to implement and test new APIs as they become available and not wait until release.
• (B) We want to ship preview/beta-builds of products that may use a beta/nightly version of GeckoView.
• (C) We want to switch to a release build as fast as possible so that apps can make use of the new version that usually includes security fixes.

Release trains

GeckoView follows the release trains of mozilla-central:

Roughly every six weeks Nightly becomes Beta and Beta becomes Release. In theory it would be possible to let the components follow those trains and always build against mozilla-central and branch simultanously. But we do not want this:

• We want to go fast and release whenever we want to.
• We do not want the overhead of multiple branches and uplifting.

Proposal

What if we duplicate the engine-gecko component so that we end up with:

• engine-gecko (tracking release)
• engine-gecko-beta (tracking beta)
• engine-gecko-nightly (tracking nightly)

This would allow us to:

• (A) Add new GeckoView APIs to engine-gecko-nightly as soon as they become available.
• (B) Use different GeckoView channels in product variants (e.g. Fenix Nightly vs. Fenix Release)
• (C) Do the integration work early and not wait until release day.

In this model every 6 week, when there is a new GeckoView release, engine-gecko-nightly would become engine-gecko-beta and engine-gecko-beta becomes engine-gecko.

Our engine abstraction would make it possible to hide the actual GeckoView version. Of course some Nightly features would not be implemented / throw an "not supported in this version" in the release version of the component.

Also: Could we automate updating the (pinned) Nightly versions in engine-gecko-nightly so that a "bot" opens PRs if no integration work is needed (and file an issue if it needs to be done manually).

┆Issue is synchronized with this Jira Task

[pocmo]

engine-gecko (tracking release)
engine-gecko-beta (tracking beta)
engine-gecko-nightly (tracking nightly)

That's only one option here. Maybe we can hide all this in the same package and use a flavor (or runtime-based implementation choosing).

[pocmo]

Having build flavors in libraries seems to be a bit painful. I managed to get sample-browser to pick the right library variant; but I'll have to test what is going to get published to jcenter.

[pocmo]

We have two options how we could achieve that:

• Option 1: Use engine-gecko and add product flavors for nightly, beta, release
• Option 2: Use separate components: engine-gecko (release), engine-gecko-beta, engine-gecko-nightly

Option 1: Product flavors

In the main source set we can keep shared code (that works across all channels) and partial implementations (e.g. BaseGeckoSession). In the product flavor source sets we can extend the base classes to add channel-specific implementations.

I implemented this partially on a branch and noticed:

• Maintenance: This gets pretty hard to maintain. Every breaking API change needs to be abstract and implemented in the channel-specific source-set. It's not straight-forward to see when this can be cleaned up because you will have to compare all implementations to see if they are equal. The implementations can accidentally develop into separate directions.

• Publishing: It's not simple to publish multiple artifacts (one per flavor) from one library project. All of the existing tools do not seem to really support that.

• Sharing: Implementations can be shared between the channels if they use the same API.

• Development: You can only have one flavor selected in Android Studio and you have to switch constantly if you want to test things (and also switch in all dependend components/apps).

• Testing: Tests need to be moved to specific source sets and need to follow the same code sharing patterns.

Option 2: Separate components

We create separate components - one per channel. On (GeckoView/Firefox) release day we can replace the release component with the beta component and the beta component with the nightly component. With that we essentially have copies of the code

• Maintenance: Easier to maintain: Only the Nightly component gets new functionality - in all other components we just stub the new API. Old implementations get cleaned up automatically as the Nightly code bubbles up and replaces the other components.

• Publishing: Simple to publish like any other component.

• Sharing: No code can be shared between the components.

• Development: Easy to navigate.. Separate gradle modules - like other components.

• Testing: We add new tests for new functionality to the nightly component and they will bubble up like the code.

[pocmo]

@csadilek ^--- What you think? Currently only option 2 seems to be maintainable to me - although I would have preferred option 1 before actually trying it. I haven't tested option 2 yet. That's what I'm going to do next.

[pocmo]

Option 2 basically rebuilds the release trains as modules.

[pocmo]

Okay, I have implemented option 2 now. That was quite easy and straight-forward. It took me quite a while to do option 1 only partially. option 2 is already done and just works. As code only needs to be added to the nightly component this isn't harder than before too. :)