Status

Release Engineering
Releases
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: rail, Assigned: rail)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

2 years ago
We need to make sure that old users update to the "patch1 version" (from bug 1079858), only then to whatever is latest. This is Windows (all versions) only. 

We have to filter users bu build ID, similar to what we have for Nightly:

Build ID:
    <20151209095500
OS Version:
    Windows_NT
(Assignee)

Comment 1

2 years ago
Ben, can you verify that I set up the watersheds properly for beta? See https://aus4-admin.mozilla.org/rules#channel:beta%20product:firefox%201234277 and https://aus4-admin.mozilla.org/rules#channel:beta%20product:firefox
Flags: needinfo?(bhearsum)
(Assignee)

Updated

2 years ago
Assignee: nobody → rail
(Assignee)

Comment 2

2 years ago
I also created watershed rules for release and esr. localtest and cdntest channels are ready, the production channels are prefixed with "-notyet" (release-notyet, beta-notyet, esr-notyet).

ESR, https://aus4-admin.mozilla.org/rules#product:firefox%20channel:esr

* 2 watershed rules:
 ** If on Windows and <38.0: update to 38.5.1 and show WNP
 ** If on Windows and Build ID <20151218095812: update to 38.5.1, no WNP
    Build ID is taken from http://ftp.mozilla.org/pub/firefox/candidates/38.5.1esr-candidates/build1/win32/en-US/firefox-38.5.1esr.json
* 2 regular rules
 ** If < 38.0: update to latest and show WNP (the watershed rule will catch Windows users, leaving this rule to Mac and Linux)
 ** Default rule: update to latest, no WNP

Beta, https://aus4-admin.mozilla.org/rules#product:firefox%20channel:beta
* If on Windows and Build ID < 20151217102820: update to Firefox-44.0b1-build2
  Build ID from http://ftp.mozilla.org/pub/firefox/candidates/44.0b1-candidates/build2/win32/en-US/firefox-44.0b1.json 
* Default rule: latest


Release: https://aus4-admin.mozilla.org/rules#product:firefox%20channel:release

* If on Windows and Build ID < 20151216175450: update to Firefox-43.0.1-build1
  Build ID from http://ftp.mozilla.org/pub/firefox/candidates/43.0.1-candidates/build1/win32/en-US/firefox-43.0.1.json
* Default rule: latest



TBD: Aurora, after patch2 lands
(In reply to Rail Aliiev [:rail] from comment #2)
>  ** If on Windows and Build ID <20151218095812: update to 38.5.1, no WNP

I believe the rule is:
** If on Windows and Build ID <20151218095812>: update to 38.5.2, no WNP

since Build ID <20151218095812> is in fact 38.5.1.
Running the ondemand update tests for ESR 38.5.2 on esr-localtest, the results seem to confirm the above watershed rules (assuming the whatsnew page rules were correctly setup):
- Windwos
   - build < 38.5.1 => updated to 38.5.1
   - build = 38.5.1 => updated to 38.5.2
- Mac & Linux
   - all builds (smaller or equal to 38.5.1) updated to 38.5.2
(Assignee)

Comment 5

2 years ago
(In reply to Florin Mezei, QA (:FlorinMezei) from comment #3)
> (In reply to Rail Aliiev [:rail] from comment #2)
> >  ** If on Windows and Build ID <20151218095812: update to 38.5.1, no WNP
> 
> I believe the rule is:
> ** If on Windows and Build ID <20151218095812>: update to 38.5.2, no WNP

The rules may look not intuitive, but this is how they work. :)
In the rule above we check if the build ID is less than 38.5.1's build ID. If so, we have to update it to 38.5.1 first. In other words, this rule catches to all Windows between 38.0 and 38.5.0 (including them). 

Don't worry about the (ugly) implementation, more important that we meet your requirements.
Rail and I talked about this a bunch in IRC, here's the recap:
* Release and ESR rules should use versions instead of buildids, because it's easier to read. (Can't do this on Beta, because the appVersion doesn't change with each Beta.)
* Need to clarify what the ESR What's New Page should be. If that's going to be a 38.5.1-specific page that only talks about SHA-2, it should probably be served to everyone upgrading to 38.5.1. If it's going to be a generic ESR 38 one, the current set of rules should be OK.

It's also worth pointing out explicitly that we can't do What's New pages that target <38.0 users updating to the latest ESR after this, because everyone will route through 38.5.1.
Flags: needinfo?(bhearsum)
We've coordinated and tested these updated for ESR, Beta and Release branches and the expected results were met.
You can find our results in the following etherpad: https://public.etherpad-mozilla.org/p/sha1-watersheds
(Assignee)

Comment 8

2 years ago
(In reply to Ben Hearsum (:bhearsum) from comment #6)
> Rail and I talked about this a bunch in IRC, here's the recap:
> * Release and ESR rules should use versions instead of buildids, because
> it's easier to read. (Can't do this on Beta, because the appVersion doesn't
> change with each Beta.)

This is done.

> * Need to clarify what the ESR What's New Page should be. If that's going to
> be a 38.5.1-specific page that only talks about SHA-2, it should probably be
> served to everyone upgrading to 38.5.1. If it's going to be a generic ESR 38
> one, the current set of rules should be OK.

I'm leaving them as is because we use a generic ESR 38 WNP.
 
> It's also worth pointing out explicitly that we can't do What's New pages
> that target <38.0 users updating to the latest ESR after this, because
> everyone will route through 38.5.1.

I am pretty sure we show the WNP to <38.0 users:
* if windows: update to 38.5.1 first and show WNP
* otherwise update to latest and show WNP
(Assignee)

Comment 9

2 years ago
I also renamed the "-notyet" channels to their normal names.
(Assignee)

Comment 10

2 years ago
(In reply to Cornel Ionce [QA] from comment #7)
> We've coordinated and tested these updated for ESR, Beta and Release
> branches and the expected results were met.
> You can find our results in the following etherpad:
> https://public.etherpad-mozilla.org/p/sha1-watersheds

Thanks a lot! I changed the rules to match version instead of build ID on the esr and release test channels, but it should be a noop for these tests.
(Assignee)

Comment 11

2 years ago
The only remaining watershed is aurora.
(Assignee)

Comment 12

2 years ago
Aurora is done in https://aus4-admin.mozilla.org/rules/277
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.