According to e-mail, this was supposed to have been done for 39.0. We want to do them in whatever the next release channel build is (39.0.1 or 40.0).

I think this is pretty straightforward. The only funny wrinkle is using {{ version }} as the first released version. This is because I don't want to forget to set it to 40.0 if we don't ship a 39.0.1. I might be able to leave that part commented out until we ship one, not sure...

Comment on attachment 8630053 [details] [diff] [review] enable win64 in release config template sweeeet!

Per e-mail, we'll wait for 40.0: 64-bit holding to 40 should not materially cause problems from my point of view. Only word of caution is that all other browsers will be pushing 64-bit by default on windows 10 and this could pose a PR issue. Risk of this becoming a story is unknown. Martin On Jul 6, 2015, at 5:10 PM, Lawrence Mandel <lmandel@mozilla.com> wrote: If 40 is enough time (as Javaum said), I think that makes more sense. We can publish with a 39.0.1 build but if we need to do a point release I really don't want new issues introduced because we decided to build Win64 builds. (We typically want to push a fix in this case ASAP.) As y'all said, we can discuss in tomorrow's channel meeting. I already see this topic on the agenda. Lawrence

We've decided not to release win64 builds in Fx40. We will wait until 41, and the improvements launching there: sandboxing and NPAPI whitelisting, and possibly some other fixes. I've spoken to the relevant folks on platform and we're fine here. Our original plan was a quiet soft-launch in 40, and to make more noise in 41 when we have added safety. We'll launch in 41.

Comment on attachment 8630467 [details] [diff] [review] only enable for 40.0 We'll need a new patch here with the version adjusted.

(In reply to Ben Hearsum (:bhearsum) from comment #5) > Comment on attachment 8630467 [details] [diff] [review] > only enable for 40.0 > > We'll need a new patch here with the version adjusted. sanity check, does this bug still block https://bugzil.la/1188493 ? anything I should be aware about prior to beta 41 release?

(In reply to Jordan Lund (:jlund) from comment #6) > (In reply to Ben Hearsum (:bhearsum) from comment #5) > > Comment on attachment 8630467 [details] [diff] [review] > > only enable for 40.0 > > > > We'll need a new patch here with the version adjusted. > > sanity check, does this bug still block https://bugzil.la/1188493 ? > > anything I should be aware about prior to beta 41 release? It does block that bug, but there's nothing actionable here until 41 is about to uplift to release. win64 is already enabled on the Beta channel, so the action here is to make sure it's enabled on mozilla-release before 41.0 is built. Probably best to land the needed patch by the Friday before we build (September 11).

Enabling WNP in the same patch to avoid merge conflicts.

touch mozRelease-firefox-win64.cfg.diff

Comment on attachment 8661407 [details] [diff] [review] configs-enable-win64_and_wnp.diff 302 jlund

Comment on attachment 8661407 [details] [diff] [review] configs-enable-win64_and_wnp.diff Review of attachment 8661407 [details] [diff] [review]: ----------------------------------------------------------------- ::: mozilla/release-firefox-mozilla-release.py.template @@ +40,2 @@ > > +# TODO: set to an actual version after first win64 on release channel build is this line still valid now that we have an actual version of 42.0? @@ +40,3 @@ > > +# TODO: set to an actual version after first win64 on release channel build > +releaseConfig['HACK_first_released_version'] = {'win64': "42.0"} at first I thought the HACK_ part was just for while it was commented out and you made a mistake but turns out that this is a valid config key: https://dxr.mozilla.org/build-central/source/tools/buildbot-helpers/release_sanity.py#253 though I must admit I don't fully grep

Comment on attachment 8661408 [details] [diff] [review] tools_add_mozRelease-firefox-win64.cfg.diff this is the easiest patch I have *ever* done! my first 0 diff.. so what I gather automation populates this with data for update verify here: https://dxr.mozilla.org/build-central/source/buildbotcustom/process/factory.py#3896 but it doesn't like it the file doesn't exist so we are touching it now before hand? eventually, it will start to look like https://dxr.mozilla.org/build-central/source/tools/release/updates/mozRelease-firefox-win32.cfg?offset=400 ?

(In reply to Jordan Lund (:jlund) from comment #12) > Comment on attachment 8661408 [details] [diff] [review] > tools_add_mozRelease-firefox-win64.cfg.diff > > this is the easiest patch I have *ever* done! my first 0 diff.. > > so what I gather automation populates this with data for update verify here: > https://dxr.mozilla.org/build-central/source/buildbotcustom/process/factory. > py#3896 > > but it doesn't like it the file doesn't exist so we are touching it now > before hand? > > eventually, it will start to look like > https://dxr.mozilla.org/build-central/source/tools/release/updates/ > mozRelease-firefox-win32.cfg?offset=400 ? The main issue is that we commit, tag and push the changes generated by that tool, but there is no "hg add" to add new files.

Comment on attachment 8661408 [details] [diff] [review] tools_add_mozRelease-firefox-win64.cfg.diff https://hg.mozilla.org/build/tools/rev/dcbb6564a776

In production

Comment on attachment 8661407 [details] [diff] [review] configs-enable-win64_and_wnp.diff https://hg.mozilla.org/build/buildbot-configs/rev/d7c1ca472072

Does this mean I should see win64 in https://ftp.mozilla.org/pub/firefox/releases/latest/ If so, then this needs to be reopened.

It's in https://ftp.mozilla.org/pub/firefox/releases/42.0/ The "latest" thingy is another bug (can't find it right now) and affects all platforms.

I asked oremj to copy the files to the "latest" directory.