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. Additional details are in https://bugzilla.mozilla.org/show_bug.cgi?id=1269811

This should be a blocker for the merge on june 6.

Ben, any news here? we plan to re-enable updates for Aurora tomorrow morning.

This is done now (rule ID: 365) Specifically marked prior 95 (5 higher than aurora's basic rule, with nothing in between) and desupported on <49.0 and matching OS: Darwin 10,Darwin 11,Darwin 12 Feel free to verify this rule with older aurora versions)

Florin can you verify this before we enable updates tomorrow? Thanks!

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #4) > Florin can you verify this before we enable updates tomorrow? Thanks! We should be able to do that tomorrow, before enabling the updates, but... which of the cases below can be tested while the updates are disabled? I'm guessing maybe only the second case? 1. OS X 10.6, 10.7, 10.8 & Aurora < latest 48 ---> we offer update to the latest Aurora 48 version 2. OS X 10.6, 10.7, 10.8 & Aurora = latest 48 ---> we display only once the app update dialog notification screenshot (https://bug843497.bmoattachments.org/attachment.cgi?id=765799) + we display the unsupported system text in the about dialog (https://bug843497.bmoattachments.org/attachment.cgi?id=765812) + no updates offered 3. OS X 10.9, 10.10, 10.11 & any older Aurora ---> we offer update to latest Aurora 49 Also could you please confirm that the scenarios above are the expected ones?

Oh I see. Of course.... we can't test it for 49 until we have enabled updates for 49! Your testing plan sounds right to me but with #2 I think we expect updates to still work with no desupport notice until the version is greater than 49. So, maybe we can just test that point again after we enable updates.

(In reply to Florin Mezei, QA (:FlorinMezei) from comment #5) > (In reply to Liz Henry (:lizzard) (needinfo? me) from comment #4) > > Florin can you verify this before we enable updates tomorrow? Thanks! > > We should be able to do that tomorrow, before enabling the updates, but... > which of the cases below can be tested while the updates are disabled? I'm > guessing maybe only the second case? > > 1. OS X 10.6, 10.7, 10.8 & Aurora < latest 48 ---> we offer update to the > latest Aurora 48 version > 2. OS X 10.6, 10.7, 10.8 & Aurora = latest 48 ---> we display only once the > app update dialog notification screenshot > (https://bug843497.bmoattachments.org/attachment.cgi?id=765799) + we display > the unsupported system text in the about dialog > (https://bug843497.bmoattachments.org/attachment.cgi?id=765812) + no updates > offered From what ben told me in IRC about this process and the decisions we came to in the bug referenced in c#0... Case 1 is wrong, we will not update to "latest Aurora 48" for any version < 49, so we can merge cases 1 and 2. The only trick is we'd not be able to verify your listed case #2's part of "no updates offered" if we test with "current latest 48" since there won't be updates offered in case 3 yet either. Soooo the ideal to me would be to test some older aurora nightly on 48, and something < 48 for sanity ~ now, and then once updates are enabled the better parts of #2 and #3.

(In reply to Justin Wood (:Callek) from comment #7) > (In reply to Florin Mezei, QA (:FlorinMezei) from comment #5) > > (In reply to Liz Henry (:lizzard) (needinfo? me) from comment #4) > > > Florin can you verify this before we enable updates tomorrow? Thanks! > > > > We should be able to do that tomorrow, before enabling the updates, but... > > which of the cases below can be tested while the updates are disabled? I'm > > guessing maybe only the second case? > > > > 1. OS X 10.6, 10.7, 10.8 & Aurora < latest 48 ---> we offer update to the > > latest Aurora 48 version > > 2. OS X 10.6, 10.7, 10.8 & Aurora = latest 48 ---> we display only once the > > app update dialog notification screenshot > > (https://bug843497.bmoattachments.org/attachment.cgi?id=765799) + we display > > the unsupported system text in the about dialog > > (https://bug843497.bmoattachments.org/attachment.cgi?id=765812) + no updates > > offered > > From what ben told me in IRC about this process and the decisions we came to > in the bug referenced in c#0... > > Case 1 is wrong, we will not update to "latest Aurora 48" for any version < > 49, so we can merge cases 1 and 2. So then if a user has Aurora 47 on OS X 10.6 do we not offer any updates at all? Shouldn't we still offer updates to the latest supported version? We had something similar for Linux with GTK < 3.4 (bug 1270358) and in the end we decided we want to let users update to the latest version that supports GTK < 3.4 (which was 45.0.2) - though initially this was a hard block so all versions < 45.0.2 would get no updates, just the unsupported system message. > The only trick is we'd not be able to verify your listed case #2's part of > "no updates offered" if we test with "current latest 48" since there won't > be updates offered in case 3 yet either. > > Soooo the ideal to me would be to test some older aurora nightly on 48, and > something < 48 for sanity ~ now, and then once updates are enabled the > better parts of #2 and #3. We'll do some testing here: https://public.etherpad-mozilla.org/p/osx-auroraupdates, and post the results.

(In reply to Florin Mezei, QA (:FlorinMezei) from comment #8) > So then if a user has Aurora 47 on OS X 10.6 do we not offer any updates at > all? Shouldn't we still offer updates to the latest supported version? We > had something similar for Linux with GTK < 3.4 (bug 1270358) and in the end > we decided we want to let users update to the latest version that supports > GTK < 3.4 (which was 45.0.2) - though initially this was a hard block so all > versions < 45.0.2 would get no updates, just the unsupported system message. Note that if the above is true, then when this hits Release all 10.6-10.8 users will be stuck on whatever Firefox version they have, instead of being updated to the latest supported version (which would be 48). Also, I was wondering, what happens now if a user tries to manually install Firefox 49 on OS X 10.6-10.8?

(In reply to Florin Mezei, QA (:FlorinMezei) from comment #8) > (In reply to Justin Wood (:Callek) from comment #7) > > (In reply to Florin Mezei, QA (:FlorinMezei) from comment #5) > > > (In reply to Liz Henry (:lizzard) (needinfo? me) from comment #4) > > > > Florin can you verify this before we enable updates tomorrow? Thanks! > > > > > > We should be able to do that tomorrow, before enabling the updates, but... > > > which of the cases below can be tested while the updates are disabled? I'm > > > guessing maybe only the second case? > > > > > > 1. OS X 10.6, 10.7, 10.8 & Aurora < latest 48 ---> we offer update to the > > > latest Aurora 48 version > > > 2. OS X 10.6, 10.7, 10.8 & Aurora = latest 48 ---> we display only once the > > > app update dialog notification screenshot > > > (https://bug843497.bmoattachments.org/attachment.cgi?id=765799) + we display > > > the unsupported system text in the about dialog > > > (https://bug843497.bmoattachments.org/attachment.cgi?id=765812) + no updates > > > offered > > > > From what ben told me in IRC about this process and the decisions we came to > > in the bug referenced in c#0... > > > > Case 1 is wrong, we will not update to "latest Aurora 48" for any version < > > 49, so we can merge cases 1 and 2. > > So then if a user has Aurora 47 on OS X 10.6 do we not offer any updates at > all? Shouldn't we still offer updates to the latest supported version? We > had something similar for Linux with GTK < 3.4 (bug 1270358) and in the end > we decided we want to let users update to the latest version that supports > GTK < 3.4 (which was 45.0.2) - though initially this was a hard block so all > versions < 45.0.2 would get no updates, just the unsupported system message. Correct. This a cost/benefit call - doing this adds complexity to the update paths, and for a small channel like Aurora it's not worth it. We will be offering the last supported version for 10.6-10.8 users on Beta, Release, and ESR as we have for GTK deprecation in the bug you referenced.

OS X 10.6-10.8 deprecation rule works fine - details here: https://public.etherpad-mozilla.org/p/osx-auroraupdates One possible issue found: after the browser starts, the following notification is displayed: http://i.imgur.com/ntnSv1W.jpg - clicking on it opens then https://bug843497.bmoattachments.org/attachment.cgi?id=765799

Sounds good to me. Thanks for hashing out the details, Florin, Callek, and Ben!

This still show up as a blocker for 49 do we want to remove that flag?

This didn't end up blocking aurora, so yes. I think we can close this bug now. Paul, could you file a follow-up bug for the issue you found in comment 11? That looks pretty ugly and should probably block release or maybe beta.

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #14) > Paul, could you file a follow-up bug for the issue you found in comment 11? > That looks pretty ugly and should probably block release or maybe beta. bug 1279906