Handle integrating GeckoView RC & Release Builds

[st3fan]

We currently only update GeckoView Beta releases.

What if we already set release_version to 84.0.00000000000000 in buildSrc/src/main/java/Gecko.kt:

internal object GeckoVersions {
    /**
     * GeckoView Beta Version.
     */
    const val beta_version = "84.0.20201203211213"

    /**
     * GeckoView Release Version.
     */
    const val release_version = "84.0.00000000000000"
}

That version does not exist obviously, but then it is simple to keep an eye on the 84 releases and pick up new ones that appear on Maven.

Using this fake version will make this A-C release unusable for use with GeckoView Release - but at the same time it will also prevent this release to be used with GV Release. So maybe that is a good thing?

The automation around this would be pretty simple. We would check for a newer release version separate from beta versions and generate a new A-C dot release just like we do now.

[st3fan]

Asking @pocmo, @JohanLorenzo and @csadilek for advice here.

[pocmo]

I don't fully understand what you want to achieve here, but note that:

• We build components and sample apps against all those versions on master and they need to be valid.
• Fenix may have a very specific release flow that uses GV Release from AC dot releases that in the first iteration had this version on beta only. But that is not true in general, e.g. for Focus. If I pick AC 68 today then I can use it with GV Nightly / Beta / Release from that point in time - depending on my needs. It would be weird to not be able to use it with GV Release until some dot release comes along that upgrades the release version.

[st3fan]

It would be weird to not be able to use it with GV Release until some dot release comes along that upgrades the release version

Agreed. So forget about my weird hack. Instead, we will just start updating release_version when Beta goes RC/Final.

What is odd though, is that GV for this A-C release will get a major version bump in a dot release. That matches with what we do for Fenix, but it does not really match what a dot release should be probably.

And how about other consumers that maybe depend on, in this case 83? Is this only a theoretical problem?

We could also, when GV goes RC, start creating 67.1.x releases. That way existing users of 67.0.x will not get surprises, and consumers that depend on the this behaviour can start following 67.1.x.

[JohanLorenzo]

Deferring the call to you three. I haven't followed the version schemes between Fenix and A-C too closely.

[st3fan]

I closed this because I think we got this covered with the android-components update-releases command, which will update GeckoView Beta and Release in "relevant" A-C versions.