Closed Bug 1269811 Opened 9 years ago Closed 9 years ago

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

Categories

(Release Engineering :: Release Requests, defect)

defect
Not set
normal

Tracking

(relnote-firefox 46+)

RESOLVED FIXED
Tracking Status
relnote-firefox --- 46+

People

(Reporter: rillian, Assigned: bhearsum)

References

Details

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/
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.
Assignee: nobody → bhearsum
Flags: needinfo?(giles)
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.
Flags: needinfo?(giles)
[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.
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?
(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.
Summary: Stop updates for Firefox 49 and later on MacOS X 10.6 → Stop updates for Firefox 49 and later on MacOS X 10.6-10.8
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.
(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.
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.
Blocks: 1255589
Flags: needinfo?(robert.strong.bugs)
Screenshots and behavior based on the UX team design are available in bug 843497.
Flags: needinfo?(robert.strong.bugs)
(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
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.
Depends on: 1270221
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.
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.
Flags: needinfo?(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.
Flags: needinfo?(bhearsum)
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!
(In reply to Kartikaya Gupta (email:kats@mozilla.com) 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!
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?
Flags: needinfo?(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.
Flags: needinfo?(bhearsum)
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?
relnote-firefox: --- → ?
Flags: needinfo?(jsavage)
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?
(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.
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.
Summary: Stop updates for Firefox 49 and later on MacOS X 10.6-10.8 → Don't update OS X 10.6-10.8 users to Firefox 49.0 or later
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.
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
Flags: needinfo?(jsavage)
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.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
See Also: → 1275602, 1275605, 1275607, 1275609
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?
Flags: needinfo?(mozillamarcia.knous)
(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.
Flags: needinfo?(mozillamarcia.knous)
Tracking this separately for each release in the bugs listed in comment 26.
(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.
You need to log in before you can comment on or make changes to this bug.