We have a couple release watersheds pointing to obsolete Firefox versions at the moment:

• #681: Migrate eligible windows 56.0 32bit users to Firefox 69.0 64bit
• #900: Bug 1563523 - locale migration

AFAIK, there's no specific reason those need to be pointing at Fx69 other than just being the last time we updated them (or what was the latest version when created). We should bump these to the latest release to avoid extra update steps for any users hitting those paths.

We will need a release watershed between Firefox 58 and Firefox 72 to prevent saved passwords from being lost. See bug 1607542.

Ryan, it looks like given where we are with Bug 1615382 that we should set 72 to be a watershed release, at least based on my understanding of watersheds (thanks Gijs). That perhaps isn't enough to resolve Bug 1615382 - the report is still a little unclear - but it might help others in a similar boat.

Jordan, can someone on your team pick this up? Sounds like we should use 72.0.2 for now.

That said, JC's request is morphing what this bug was originally filed for (adding a new generic watershed rule for Fx72 vs. updating a few already-existing rules to point at a newer version).

assigning current releaseduty

I've created a new release blob for the locale migrations in rule 681, using https://hg.mozilla.org/build/braindump/file/tip/releases-related/migrate-locales.py as in the original bug. I've scheduled an update to the rule to point to this instead.

The win64 migration rule doesn't look to have anything special in the release blob, so I've scheduled the rule update to use the default 72.0.2-build1 release.

I've also scheduled the addition of a catch-all watershed for <72.0.2 to go to 72.0.2, if I've read comment #2 correctly.

Incidentally we should probably reprioritise some of the release channel rules as we don't have a lot of 'space' in the priority list between this new one and the main Firefox:release rule.

Thanks, I've signed off on the changes and they're showing as live now.

One question - do we need to do anything with rule #827 at this point? I'm also wondering if #900 should be higher priority than it.

Also, should we be showing a WNP to users updating to 72.0.2 at this point?

(In reply to Simon Fraser [:sfraser] ⌚️GMT from comment #6)

I've created a new release blob for the locale migrations in rule 681, using https://hg.mozilla.org/build/braindump/file/tip/releases-related/migrate-locales.py as in the original bug. I've scheduled an update to the rule to point to this instead.

The win64 migration rule doesn't look to have anything special in the release blob, so I've scheduled the rule update to use the default 72.0.2-build1 release.

I've also scheduled the addition of a catch-all watershed for <72.0.2 to go to 72.0.2, if I've read comment #2 correctly.

We ended up reverting this because it was doing a 32-bit to 32-bit update. It's not quite obvious, but the migration blobs have an important tweak in them: the "WINNT_x86-msvc-x64" platform gets aliased to "WINNT_x86_64-msvc" (instead of its usual "WINNT_x86-msvc"). (Compare https://aus-api.mozilla.org/api/v1/releases/Firefox-69.0-build2-win64-migration vs https://aus-api.mozilla.org/api/v1/releases/Firefox-72.0.2-build1)

(In reply to Ryan VanderMeulen [:RyanVM] from comment #10)

Also, should we be showing a WNP to users updating to 72.0.2 at this point?

Your call, I guess. I don't have strong feelings either way. Shouldn't be a big deal.

(In reply to Ryan VanderMeulen [:RyanVM] from comment #9)

Thanks, I've signed off on the changes and they're showing as live now.

One question - do we need to do anything with rule #827 at this point? I'm also wondering if #900 should be higher priority than it.

I think this is fine as is. Anyone hitting rule 827 will drop their "distribution" identifier, and continue further down in the rules. Unless they need to do the locale migration prior to doing that, I don't see why the order of these two rules matters.

(In reply to bhearsum@mozilla.com (:bhearsum) from comment #11)

(In reply to Ryan VanderMeulen [:RyanVM] from comment #10)

Also, should we be showing a WNP to users updating to 72.0.2 at this point?

Your call, I guess. I don't have strong feelings either way. Shouldn't be a big deal.

In that case, let's move forward with that. No need to spam our users multiple times when updating from an older release.

(In reply to Ryan VanderMeulen [:RyanVM] from comment #12)

(In reply to bhearsum@mozilla.com (:bhearsum) from comment #11)

(In reply to Ryan VanderMeulen [:RyanVM] from comment #10)

Also, should we be showing a WNP to users updating to 72.0.2 at this point?

Your call, I guess. I don't have strong feelings either way. Shouldn't be a big deal.

In that case, let's move forward with that. No need to spam our users multiple times when updating from an older release.

These have all been scheduled. We're updating:
https://balrog.services.mozilla.com/rules?product=Firefox&channel=release#ruleId=957 to switch the general watershed to the no-WNP release
https://balrog.services.mozilla.com/rules?product=Firefox&channel=release#ruleId=681 to bump the 64-bit migration to 72.0.2 (no WNP)
https://balrog.services.mozilla.com/releases#Firefox-72.0.2-build1-migrate-locales to get rid of WNP for the locale migration

I've removed my own sign off and am looking for another RelEnger to double check my changes.

(In reply to bhearsum@mozilla.com (:bhearsum) from comment #13)

(In reply to Ryan VanderMeulen [:RyanVM] from comment #12)

(In reply to bhearsum@mozilla.com (:bhearsum) from comment #11)

(In reply to Ryan VanderMeulen [:RyanVM] from comment #10)

Also, should we be showing a WNP to users updating to 72.0.2 at this point?

Your call, I guess. I don't have strong feelings either way. Shouldn't be a big deal.

In that case, let's move forward with that. No need to spam our users multiple times when updating from an older release.

These have all been scheduled. We're updating:
https://balrog.services.mozilla.com/rules?product=Firefox&channel=release#ruleId=957 to switch the general watershed to the no-WNP release
https://balrog.services.mozilla.com/rules?product=Firefox&channel=release#ruleId=681 to bump the 64-bit migration to 72.0.2 (no WNP)
https://balrog.services.mozilla.com/releases#Firefox-72.0.2-build1-migrate-locales to get rid of WNP for the locale migration

I've removed my own sign off and am looking for another RelEnger to double check my changes.

Aki had a look but wasn't able to sign off. I added my own sign off again, and we're now live. I think we're all done here now?

Looks great, thanks Simon and Ben!

I ran a few tests on a W10 64bit machine today and I saw that something changed in the way Fx brings updates from old versions < 56.0.
I saw that using a Fx 55.0 x32bit will update to Fx 56.0 32bit and just stop there, no more updates are served after that. I was expecting to get:

55.0 32-bit ➝ 56.0 32-bit ➝ 72.0.2 64bit ➝ latest 64bit
If I am not mistaken. Any thoughts?

Do you have the corresponding update log?

Here is what Browser Console shows when I try to update from Fx 56.0 32bit.

(In reply to Bogdan Maris [:bogdan_maris], Release Desktop QA from comment #16)

I ran a few tests on a W10 64bit machine today and I saw that something changed in the way Fx brings updates from old versions < 56.0.
I saw that using a Fx 55.0 x32bit will update to Fx 56.0 32bit and just stop there, no more updates are served after that. I was expecting to get:

55.0 32-bit ➝ 56.0 32-bit ➝ 72.0.2 64bit ➝ latest 64bit
If I am not mistaken. Any thoughts?

Yes, this is what I would expect. I just had a look at Balrog and I see the error that was made. The scheduled change on https://balrog.services.mozilla.com/releases#Firefox-72.0.2-build1-win64-migration should fix it up.

(In reply to bhearsum@mozilla.com (:bhearsum) from comment #19)

(In reply to Bogdan Maris [:bogdan_maris], Release Desktop QA from comment #16)

I ran a few tests on a W10 64bit machine today and I saw that something changed in the way Fx brings updates from old versions < 56.0.
I saw that using a Fx 55.0 x32bit will update to Fx 56.0 32bit and just stop there, no more updates are served after that. I was expecting to get:

55.0 32-bit ➝ 56.0 32-bit ➝ 72.0.2 64bit ➝ latest 64bit
If I am not mistaken. Any thoughts?

Yes, this is what I would expect. I just had a look at Balrog and I see the error that was made. The scheduled change on https://balrog.services.mozilla.com/releases#Firefox-72.0.2-build1-win64-migration should fix it up.

Should be fixed now. The URL from your logs is returning a better response now.

Thank you!
It works now: 55.0 32-bit ➝ 56.0 32-bit ➝ 72.0.2 64bit ➝ latest 64bit

I made some changes to the release-localtest and release-cdntest rules today to have these match the updates from this bug on release. Thanks to :dcicas for flagging the discrepancy.

Nick mentioned that we might see some nice update-verify runtime wins if we added the watershed to the Beta channel too. Is anybody interested in doing that?

That would just be the locale migration and 72.0.2 general watershed, right? I don't see a win64 migration rule there at the moment.

Yeah, sounds correct to me.