Clean up usage of get-moz-build-date script

We have different ways of using get-moz-build-date but should converge on the projects/common one. Additionally, we don't need to spread var/copyright_year over the projects. Rather, let's declare that in rbm.conf.

added Next + 1 deleted label

added Maintenance label

changed the description

mentioned in merge request !79 (closed)

added Doing label and removed Next label

added Next label and removed Doing label

added Backlog label and removed Next label

unassigned @gk

added 1 deleted label and removed 1 deleted label

added Next label and removed Backlog label

added Roadmap::Future label and removed Next label

added Task label

marked this issue as related to tor-browser#41540 (closed)

added Build System label

Why can't we get rid of this script, instead, and use Firefox's commit date?

I've just discovered that the HTTPS error logic uses the build date to check if the clock is wrong (well, as a fallback, remote settings is considered the first source of truth).

For alphas, currently the build date is in the future (20230706040101 for 12.5a3). So, we will always have a "wrong clock" warning instead of "expired certificate".

Maybe at the moment it's the only place where it is used like this, but we should assume Firefox devs take for granted it's a date in the past.

I'm quite sure we've discussed this somewhere, but I can't find where, and this seems the most appropriate place to me, at the moment.

Why can't we get rid of this script, instead, and use Firefox's commit date?

If I remember correctly, the build id needs to increase for each release, otherwise the updater refuses the update. And sometimes we have two releases based on the same Firefox commit, so we can't just use the Firefox's commit date.

Maybe we can add an option in rbm.conf to set the release date, and use that as the build id.

This is related to tor-browser#41743.

Maybe we can add an option in rbm.conf to set the release date, and use that as the build id.

I imagine myself forgetting to do so (especially in a big hurry, e.g., for an emergency release).

sometimes we have two releases based on the same Firefox commit, so we can't just use the Firefox's commit date.

True, but we still have to bump the version string (and rebuild Firefox for that ).

So, what if we used $commitDate + $version, (e.g., $commitDate + $majorInMinutes + $minorInSeconds)?

Caveats:

• we already have a system: to get started, we will need to check that we have a date that comes after the last one we created with the old system. We could use max($lastDate + $someOffset, $commitDate) instead of just $commitDate at the beginning (and then eventually remove the max)
• we need to properly handle overflow (we can do the math in seconds, e.g., from Unix epoch, and then convert back to the format we need)
• we need to properly handle the .5 (well, it's very unlikely that we'll be in a case in which we need to distinguish between majors in the same update channel, but we can do it to be on the safe side; working in seconds already solves this problem, too, but maybe we could also multiply by 120, instead of 60)
• some version strings aren't version numbers (e.g., nightlies and testbuilds): we could keep handling nightlies as a special case, like we already do, after all they're already tied to a date, and we could just use the commit date for testbuilds (they usually don't need to be updated, I use nightlies when I need to test the updater, with custom dates that I always get wrong at first attempts)

Found yet another usage of the buildID as date, but it should not be a big deal: it's used in BrowserGlue.jsm to decide whether to check for updates when app.update.checkInstallTime is true.

marked this issue as related to tor-browser#41743

Could we target this issue for 13.0a1?

I.e., remove all the scripts, except the one in projects/common, and modify it to use the git commit date whenever possible.

We're already past the date of 12.5a7, so we shouldn't have problems with it.

> projects/common/get-moz-build-date 2023 12.5a7
export MOZ_BUILD_DATE=20230706080101
> projects/common/get-moz-build-date 2023 13.0a1
export MOZ_BUILD_DATE=20230801020101

I can also take this, but I'd do it after !738 (merged).

Could we target this issue for 13.0a1?

Good idea.

I can also take this, but I'd do it after !738 (merged).

I think I can do it this week.

assigned to @boklm

added Doing label

mentioned in merge request !756 (merged)

marked this issue as related to #40848 (closed)

closed with merge request !756 (merged)

marked this issue as related to #40873 (closed)

marked this issue as related to #40965 (closed)

marked this issue as related to #40966 (closed)