1269811 - Don't update OS X 10.6-10.8 users to Firefox 49.0 or later

Status: RESOLVED FIXED

(Release Engineering :: Release Requests, defect)

Description

[Ralph Giles (:rillian)]

We've discontinued support for MacOS X 10.6-10.8[1] and today bumped the minimum MacOS target to 10.7. That means that starting with tomorrow's nightly, Firefox 49 won't run on MacOS prior to 10.7.

We should adjust the config of the update server to stop sending updates to users on 10.6 if they'd get Firefox 49 or later to avoid breaking their current installs.

[1] https://blog.mozilla.org/futurereleases/2016/04/29/update-on-firefox-support-for-os-x/

Comment 1

[[e-mail] (:bhearsum)]

I've set this up such that 10.6 users will continue to receive updates to the 20160503030421 build in perpetuity. We'll want to do the same for Aurora, Beta, Release and ESR as this changes makes it to those channels. Ralph, is this expected to ride with 49?



For RelEng, I duplicated the existing Firefox nightly rule, raised the priority to 95, set osVersion to "Darwin 10", and pointed the mapping at Firefox-mozilla-central-nightly-20160503030421. This become rule 340.

Comment 2

[Ralph Giles (:rillian)]

Thanks, Ben. Yes, this is expected to rid the trains. There will be similar stops for MacOS X 10.7 and 10.8 coming after bug 1269798 is resolved.

Comment 3

[[e-mail] (:bhearsum)]

[Tracking Requested - why for this release]:

(In reply to Ralph Giles (:rillian) needinfo me from comment #2)
> Thanks, Ben. Yes, this is expected to rid the trains. There will be similar
> stops for MacOS X 10.7 and 10.8 coming after bug 1269798 is resolved.

OK, great. Rail and Liz - I'm cc'ing you to make sure you're both aware that we'll need a similar change in Balrog for other channels, per comment #1. I'll leave myself assigned to this for now, but if I'm not around when it needs to happen someone will need to do it.

Comment 4

[Gregory Szorc [:gps]]

We /could/ disable updates to 10.7 and 10.8 now if we wanted, as they are no longer officially supported on 49+. However, stopping updates before we actually break them feels a bit weird. That being said, now that we've stopped reporting test automation for 10.6, these builds could break any time. If we don't disable updates to 10.7 and 10.8, we could attempt to update someone to a busted package. This feels bad.

So my vote is to go ahead and disable 10.7 and 10.8 updates now before we break something. Better safe than sorry, right?

Comment 5

[[e-mail] (:bhearsum)]

(In reply to Gregory Szorc [:gps] from comment #4)
> We /could/ disable updates to 10.7 and 10.8 now if we wanted, as they are no
> longer officially supported on 49+. However, stopping updates before we
> actually break them feels a bit weird. That being said, now that we've
> stopped reporting test automation for 10.6, these builds could break any
> time. If we don't disable updates to 10.7 and 10.8, we could attempt to
> update someone to a busted package. This feels bad.
> 
> So my vote is to go ahead and disable 10.7 and 10.8 updates now before we
> break something. Better safe than sorry, right?

Let's do that. Dead-ending them on the same version reduces the number of Balrog rules we need, too.

I've updated the earlier created rule to match on Darwin 10, 11, and 12.

Comment 6

[Nick Thomas [:nthomas] (UTC+12)]

Ben, if we used the DesupportBlob and converted the rule to version-based instead of channel, perhaps we can just write one rule and avoid work at each merge ? Sorta like the GTK3 case, only we still have a channel restriction there.

Comment 7

[[e-mail] (:bhearsum)]

(In reply to Nick Thomas [:nthomas] from comment #6)
> Ben, if we used the DesupportBlob and converted the rule to version-based
> instead of channel, perhaps we can just write one rule and avoid work at
> each merge ? Sorta like the GTK3 case, only we still have a channel
> restriction there.

We talked about this on IRC a bit and decided that we'll go with the DesupportBlob with a version match for now. The benefit of this is that it will automatically ride the channels. The downside is that it won't serve users the latest build, merely point them at an URL explaining why they can't update. This should be fine for nightly/aurora/beta, but we may want to do something different for users to make sure 10.6-10.8 users can at least get to the last point release of 48.0. We can cross that bridge later, though.

Comment 8

[Benjamin Smedberg]

Robert, could you give me an overview/screenshots of what the experience would be with an explanation URL? Now that we have system addon support, it may be better for balrog to simply return no updates and use a system addon to provide more permanent UI, along the lines of what Bram is designing for update orphaning.

Comment 9

[Robert Strong (they/them - no direct email)]

Screenshots and behavior based on the UX team design are available in bug 843497.

Comment 10

[Robert Strong (they/them - no direct email)]

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #9)
> Screenshots and behavior based on the UX team design are available in bug
> 843497.

The gist of it

The app update dialog notification is only shown once per UX to avoid annoying users.
app update dialog notification screenshot #attachment 765799 [details]

about dialog screenshot #attachment 765812 [details]

The rationale for the strings that were used with input from UX, security, and myself can be found in several of the comments of bug 843497

Comment 11

[Benjamin Smedberg]

ok, yeah we should push the desupport URL. We may also end up pushing a variant of the insecure browser/update orphaning UI to these people as well.

Comment 12

[[e-mail] (:bhearsum)]

I've updated the Balrog rule to serve the unsupported information instead of no update. This can be seen in URLs such as:
https://aus4.mozilla.org/update/3/Firefox/49.0a1/20141202185629/Darwin_x86_64-gcc3-u-i386-x86_64/en-US/nightly/Darwin%2010.0.2/default/default/update.xml

I've made the new rule match Firefox, <49.0, Darwin 10/11/12. Note that "49.0a1" is considered less than "49.0", so nightly users will be correctly caught by it.

Comment 13

[Nick Thomas [:nthomas] (UTC+12)]

I've re-added a channel restriction of nightly* to that rule, because I realized were offering it on aurora/beta/release too. Sorry for being boneheaded.

Comment 14

[Benjamin Smedberg]

Ben, please alter this to use this URL from bug 1270221:

If possible: https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/osx
Or if not: https://support.mozilla.org/kb/firefox-osx

Comment 15

[[e-mail] (:bhearsum)]

(In reply to Nick Thomas [:nthomas] from comment #13)
> I've re-added a channel restriction of nightly* to that rule, because I
> realized were offering it on aurora/beta/release too. Sorry for being
> boneheaded.

Whoops, duh. Thanks for that.

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #14)
> Ben, please alter this to use this URL from bug 1270221:
> 
> If possible:
> https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/osx
> Or if not: https://support.mozilla.org/kb/firefox-osx

We don't support substitution in this URL, so I used the latter. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1270827 to look at adding substitution in the future.

Comment 16

[Kartikaya Gupta (email:[e-mail])]

FYI I have a 10.6 machine running Nightly and I got a dialog over the weekend saying that it couldn't update and pointed me to the KB article. So that all went pretty much as expected, thanks!

Comment 17

[[e-mail] (:bhearsum)]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #16)
> FYI I have a 10.6 machine running Nightly and I got a dialog over the
> weekend saying that it couldn't update and pointed me to the KB article. So
> that all went pretty much as expected, thanks!

Thanks for verifying that!

Comment 18

[Lawrence Mandel [:lmandel] (use needinfo)]

The intention is to drop support for OSX 10.6-10.8 in Firefox 48. Can we easily apply the change to Aurora 48 as well?

Comment 19

[[e-mail] (:bhearsum)]

(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #18)
> The intention is to drop support for OSX 10.6-10.8 in Firefox 48. Can we
> easily apply the change to Aurora 48 as well?

Yep, it only takes a minute to apply.

Comment 20

[Liz Henry (:lizzard) (relman/hg->git project)]

Release Note Request (optional, but appreciated)
[Why is this notable]:
[Suggested wording]:
[Links (documentation, blog post, etc)]:

Tracking for 48 since this is a big change. We could also add it to release notes

Joni can you make sure we get good content into https://support.mozilla.org/en-US/kb/firefox-osx about dropping support?

Comment 21

[Nils Ohlmeier [:drno]]

I just described the user experience over here https://bugzilla.mozilla.org/show_bug.cgi?id=1269790#c8

Two questions/observations:
1) Yes we need content for https://support.mozilla.org/en-US/kb/firefox-osx as the "Learn more" point to this article with no content.
2) The machine I tested this on was running Fx Nightly 40 and refused to update at all. I would have expected that it updates itself to 48 (last working version) and then refuses further updates. Is this technically not possible to accomplish? Or this something we would at least point the user to the latest working version for their OS in the above mentions support article?

Comment 22

[[e-mail] (:bhearsum)]

(In reply to Nils Ohlmeier [:drno] from comment #21)
> 2) The machine I tested this on was running Fx Nightly 40 and refused to
> update at all. I would have expected that it updates itself to 48 (last
> working version) and then refuses further updates. Is this technically not
> possible to accomplish? Or this something we would at least point the user
> to the latest working version for their OS in the above mentions support
> article.

This is the expected behaviour, per comment #7. It's possible to do what you describe, but I don't think it's worth the effort on Nightly or Aurora. We should probably do it for Beta/Release/ESR though.

Comment 23

[[e-mail] (:bhearsum)]

There's been a lot of confusion in this bug around what the last version of Firefox to support OS X 10.6-10.8 will be. bsmedberg clarified in https://groups.google.com/forum/#!msg/mozilla.dev.platform/gXZj0rQWEfI/zcq207jeAAAJ:

"As of this point, I expect that Firefox 48 will still run on 10.6-10.8 and the first release to drop support will be Fx49."

I'm updating the summary of this bug to more clear...the current title is a bit hard for me to parse.

Comment 24

[[e-mail] (:bhearsum)]

RelEng, here's the plan for us, by channel:
* nightly: Create a rule that points anybody on 10.6-10.8 at the OSX-10.6-10.8-Desupport blob. (DONE - rule id #340)

* aurora: Just before 49.0 ships to the aurora channel, create a rule that points anybody on 10.6-10.8 at the OSX-10.6-10.8-Desupport blob.

* beta: When we ship the final 48.0 Beta, create two rules:
** 1) Matches buildid < the final beta's buildid and OS X 10.6-10.8, and points them at the final 48.0 Beta
** 2) Matches the final beta's buildid _exactly_ and OS X 10.6-10.8, and points them at the OSX-10.6-10.8-Desupport blob.

* release: When we ship 48.0, create two rules:
** 1) Matches version < 48.0 and OS X 10.6-10.8, and points them at the Firefox 48.0 blob.
** 2) Matches version = 48.0 and OS X 10.6-10.8, and points them at the OSX-10.6-10.8-Desupport blob.

* esr: When we ship 45.8.0esr, create two rules:
** 1) Matches version < 45.8.0 and OS X 10.6-10.8, and points them at the Firefox 45.8.0 blob.
** 2) Matches version = 45.8.0 and OS X 10.6-10.8, and points them at the OSX-10.6-10.8-Desupport blob.

If we ship point release to 48.0 or 45.8.0, we'll to need to update the release/esr rules version filters to use the new version numbers. Eg: if we ship 48.0.1, both of the rules created above should use that instead of 48.0.

Comment 25

[Joni Chan]

I have a first draft up here: https://support.mozilla.org/en-US/kb/firefox-osx

Feel free to comment in this Google Doc (or edit the article directly) if you'd like to suggest any changes: https://docs.google.com/a/mozilla.com/document/d/1OFLedjiKc9kP7XcaK9tm9VKLAfM1AZrBmNiFX0-bgLc/edit?usp=sharing

Comment 26

[[e-mail] (:bhearsum)]

I probably won't be the one implementing this on other channels. I filed other bugs for each channel:
https://bugzilla.mozilla.org/show_bug.cgi?id=1275602
https://bugzilla.mozilla.org/show_bug.cgi?id=1275605
https://bugzilla.mozilla.org/show_bug.cgi?id=1275607
https://bugzilla.mozilla.org/show_bug.cgi?id=1275609

With that done, there's nothing left to do here AFAIK. If we want to change the URL we give deprecated users, please file a new bug. It's currently set to https://support.mozilla.org/kb/firefox-osx.

Comment 27

[Liz Henry (:lizzard) (relman/hg->git project)]

We may want to put a release note into both 48 beta and 49 aurora notes (with a link to the support page) as well as changing the system requirements. 
Marcia can you add the note for 49?

Comment 28

[Marcia Knous [:marcia]]

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #27)
> We may want to put a release note into both 48 beta and 49 aurora notes
> (with a link to the support page) as well as changing the system
> requirements. 
> Marcia can you add the note for 49?

yes, confirming that the note is in there, and the system requirements have been adjusted to reflect the change.

Comment 29

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracking this separately for each release in the bugs listed in comment 26.

Comment 30

[[e-mail] (:bhearsum)]

(In reply to Ben Hearsum (:bhearsum) from comment #24)
> RelEng, here's the plan for us, by channel:
> * release: When we ship 48.0, create two rules:
> ** 1) Matches version < 48.0 and OS X 10.6-10.8, and points them at the
> Firefox 48.0 blob.
> ** 2) Matches version = 48.0 and OS X 10.6-10.8, and points them at the
> OSX-10.6-10.8-Desupport blob.
> 
> * esr: When we ship 45.8.0esr, create two rules:
> ** 1) Matches version < 45.8.0 and OS X 10.6-10.8, and points them at the
> Firefox 45.8.0 blob.
> ** 2) Matches version = 45.8.0 and OS X 10.6-10.8, and points them at the
> OSX-10.6-10.8-Desupport blob.
> 
> If we ship point release to 48.0 or 45.8.0, we'll to need to update the
> release/esr rules version filters to use the new version numbers. Eg: if we
> ship 48.0.1, both of the rules created above should use that instead of 48.0.

Turns out part 2 for release and esr is wrong - it ends up showing users "out of date" dialogs before 49.0 has shipped. We need to do _that_ part right before we ship 49.0 to release, and 52.3.0 to esr. I'll be updating our notes to reflect this.