By incrementing 64-bit Firefix's build ID to be greater than 32-bit Firefix's, we can throttle the roll-out of 64-bit Firefox to 32-bit Firefox users, even when the 64-bit update has the same browser version.

We may not need this change. We can lie the build id in update.xml without changing anything. To make sure this works I'm going to create a special channel and test it.

It looks like we don't need to implement this. Here is what I did. * Downloaded 51.0b9 en-GB 32-bit and installed it on a Win64 VM * Downloaded Firefox-51.0b9-build1.json blob (next attachment) which contains the current update meta-data. ** Removed linux/mac related entries ** Removed all partial entries ** Aliased all win32 based entries to WINNT_x86_64-msvc ** Bumped buildID from 20161219140923 to 20161219140924 ** saved as Firefox-51.0b9-build1-win64.json (current attachment) ** Uploaded the new blob to Balrog * Created 3 rules in Balorg to point WINNT_x86-msvc-x86, WINNT_x86-msvc-x64, and WINNT_x86-msvc separately (per http://mozilla-balrog.readthedocs.io/en/latest/database.html#rules Build Target can't use coma separated list) to this blob on the "beta-win64" channel. We may need to revisit the list of the build targets, or maybe add extra restrictions based on the UA string. * Changed the update channel in the app dir to "beta-win64" * Checked for the updates. ** The URL was https://aus5.mozilla.org/update/6/Firefox/51.0/20161219140923/WINNT_x86-msvc-x64/en-GB/beta-win64/Windows_NT%206.1.1.0%20(x64)(noBug1296630v1)/SSE3/default/default/update.xml?force=1 ** Looked like this http://people.mozilla.org/~raliiev/sattap/eefdd088.png * applied updated, restarted Firefox, checked for updates ** The URL was https://aus5.mozilla.org/update/6/Firefox/51.0/20161219140923/WINNT_x86_64-msvc-x64/en-GB/beta-win64/Windows_NT%206.1.1.0%20(x64)(noBug1296630v1)/SSE3/default/default/update.xml?force=1 ** No updates: http://people.mozilla.org/~raliiev/sattap/4d22a9f8.png \o/

The initial blob, can be diffed if needeed

The channel (beta-win64) is still available, I'll delete it some time next week.

(In reply to Rail Aliiev [:rail] ⌚️ET from comment #2) > It looks like we don't need to implement this. Here is what I did. > > * Downloaded 51.0b9 en-GB 32-bit and installed it on a Win64 VM > > * Downloaded Firefox-51.0b9-build1.json blob (next attachment) which > contains the current update meta-data. > ** Removed linux/mac related entries > ** Removed all partial entries > ** Aliased all win32 based entries to WINNT_x86_64-msvc > ** Bumped buildID from 20161219140923 to 20161219140924 So you bumped the buildID advertised on Balrog but not the actual buildID of the 64-bit build? When you say we don't need to implement this, do you mean we don't need to bump 64-bit Firefox's buildID when building but we will need to bump the advertised buildID on Balrog?

Correct. The Balrog advertised buildID is the only thing that the client looks at. After the update (MAR file) is downloaded, there are no extra checks against buildID (iirc we still won't let users downgrade the version).