Bug 40160 00

Closes #40160 (closed)

changed milestone to %Tor Browser: 10.0

cc @acat

Here are a couple of things we should fix:

1. We should pick up the commit from master that fix tor-browser#40212 (closed).
2. You should cherry-pick 127992a0, too, and remove that part from your 49c657e2.

We need to be careful here. We already have gradle_dependencies_version: 9 on master, yet the dependencies are not the same. So, if someone built e.g. the latest alpha and is now about to build the stable they would not use the dependencies we intend to use for stable. I think the build would actually fail for those folks.

We could fix that by just being careful making sure when we bump this version number it has never been used before anywhere in case the deps do not match. Or we could have a policy reserving the odd numbers for master while even numbers for the respective maint branch. Or maybe even something else.

We need to be careful here. We already have gradle_dependencies_version: 9 on master, yet the dependencies are not the same. So, if someone built e.g. the latest alpha and is now about to build the stable they would not use the dependencies we intend to use for stable. I think the build would actually fail for those folks.

Thanks, I missed that because I didn't consider that collision across branches and I thought I previously downloaded the dependencies in the -9 directory (in this case) in a previous test build.

We could fix that by just being careful making sure when we bump this version number it has never been used before anywhere in case the deps do not match. Or we could have a policy reserving the odd numbers for master while even numbers for the respective maint branch. Or maybe even something else.

I think I'd prefer implementing #28595

I'll also mention here: I am concerned that some dependencies (same package name and version number) have different sha256 hash values between what I computed yesterday and the values that landed on master. This is primarily a concern for the overall reproducibility of the android builds over longer periods of time. I assume the developers of these packages have the ability to update a published package without bumping the version number.

Matthew Finkel:

Matthew Finkel commented on a discussion on projects/android-components/config: !131 (comment 2716950)

variant: '[% IF c("var/release") %]Release[% ELSE %]Beta[% END %]'

var:

• android_components_version: 63.0.1
• torbrowser_branch: 10.5

• android_components_version: 63.0.9
• torbrowser_branch: 10.0 container: use_container: 1

  This should be updated when the list of gradle dependencies is changed.

• gradle_dependencies_version: 8

• gradle_dependencies_version: 9

I'll also mention here: I am concerned that some dependencies (same package name and version number) have different sha256 hash values between what I computed yesterday and the values that landed on master. This is primarily a concern for the overall reproducibility of the android builds over longer periods of time. I assume the developers of these packages have the ability to update a published package without bumping the version number.

Yep, I've seen that while prepping the switch to fenix 84. The case I looked at was just reformatting the file... :(

Here are a couple of things we should fix:

1. We should pick up the commit from master that fix tor-browser#40212 (closed).

Actually, I think we are good here. As I picked the mobile part back then when merging. It's just the desktop part that is omitted which is okay-ish. I wonder, though, whether it would be worth cherry-picking those things anyway to keep the diff to master as small as possible. My gut feeling is "yes, please" but I am fine if we say "no".

I don't think the additional small diff between branches is important right now, but we'll probably appreciate it in the future. I picked the desktop patch onto the beginning of the new prep branch.

3. Similar to 1) I think it would be beneficial if you cherry-picked the Fenix related changes from master first (that is commits 76833c13 and 098ca6fa) and then build your changes on top of them.

I considered this while I was working on it, and I decided against it, because in the end the upgrades change a large number of lines and I didn't see a benefit in backporting a patch from 10.5 when it would be mostly re-written. However, I see there is a benefit in review (time) cost, even if there is not much benefit/savings in development cost. As such, backporting all patches related to a version-bump is a good policy.

assigned to @sysrqb and unassigned @gk

Superseded by !132 (closed)

closed