Per our discussion in Whistler, we want to bump the ESR minor version (i.e. 68.x -> 68.y) on merge day at the start of the cycle rather than during RC week.

Copying & pasting the relevant parts of the email summarizing that discussion:

To summarize the rationale for the change:

• We currently wait until RC week to do the main ESR version bump (i.e. 60.7.x -> 60.8.0)
• In the past, this has caused us to nearly ship security updates intended for the next cycle in a dot release (because fixes landed on the default branch and we forgot they were there), and I believe there was one past instance of us actually doing so.
• This previous point also causes Release Management to often delay approvals for ESR uplifts until late in the cycle to minimize churn on the branch in the event of a dot release
• With Fennec moving to ESR, Nightly and Beta builds are going to be bumping the version at the beginning of the cycle, leaving Release builds in a weird state where they're following Desktop norms while their Nightly & Beta counterparts are doing something different
• Furthermore, delaying approval of ESR uplifts will limit the usefulness of Fennec pre-release testing
• Nobody seems to have a good recollection for why things are the way they are, though suspicions are that it goes back to Buildbot days when relbranches were more annoying to deal with

Going forward, we will now do the version bump at the start of the cycle. This means that:

• Any ESR dot releases will need to come off a relbranch instead of default. All of our existing tooling can handle that already. Over the lifespan of ESR60, this would have required 3 instances of relbranches needed, which doesn't seem onerous.
• Release Management can be more proactive with approving ESR uplifts, which reduces overhead and makes things better for Fennec.
• Release Engineering will need to ensure that in the event of a dot release, the subsequent minor version bump (i.e. 60.7.1 -> 60.7.2) happens on the branch that release was shipped from, not on default.

We will need to update ship-it to generate the correct version for ESR builds here and here. We should probably update it to use mozilla-version at the same time.

(I also wonder if it would be better to move that logic in-tree, rather than in an external service).

Good news, mozilla-version is being added in [1] :)

[1] https://github.com/mozilla/release-services/pull/2231/files#diff-ae9b2045812d1ad31281348eea2154a3R85

We've been doing this for a long time now.