Closed Bug 1444486 Opened 7 years ago Closed 7 years ago

Setup WNP for users coming from <59.0 and receiving any 59.0.x release

Categories

(Release Engineering :: Release Requests, enhancement)

enhancement
Not set
normal

Tracking

(firefox59blocking fixed)

RESOLVED FIXED
Tracking Status
firefox59 blocking fixed

People

(Reporter: erenaud, Unassigned)

References

()

Details

Request is to turn on the /whatsnew page in Firefox 59.0.x releases (and keep it on for 59.0.x -> (all the dot releases)) The diff between the previous request https://bugzilla.mozilla.org/show_bug.cgi?id=1438653 to show the /whatsnew page is the number of locales. For the mobile CTA version of WNP, what was shown in all 58.x releases, that content is available to 74 locales as follows: af, ar, ast, az, be, bg, bs, ca, cak, cs, cy, da, de, dsb, el, en-GB, en-US, eo, es-AR, es-CL, es-ES, es-MX, et, eu, fa, ff, fi, fr, fy-NL, ga-IE, gu-IN, he, hi-IN, hsb, hu, hy-AM, id, is, it, ja, ja-JP-mac, ka, kab, kk, ko, lij, lt, ml, mr, ms, my, nb-NO, nl, nn-NO, pa-IN, pl, pt-BR, pt-PT, rm, ro, ru, sk, sl, sq, sr, sv-SE, ta, te, th, tr, uk, vi, zh-CN, zh-TW
Amending that list after discussing w. agibson. This needs to accord the locales we've established in 1438653#c15 an, bg, bs, cak, cs, cy, da, de, dsb, en-US, eo, es-AR, es-CL, es-ES, es-MX, et, fa, fi, fr, fy-NL, gu-IN, hsb, hu, hy-AM, it, ja, ja-JP-mac, ka, ms, nb-NO, nl, nn-NO, pl, pt-BR, pt-PT, ru, sk, sl, sq, sv-SE, tr, uk, zh-CN, zh-TW To confirm the functionality: Someone updating from an older major version will get the FxA form: https://www.mozilla.org/en-US/firefox/59.0/whatsnew/?oldversion=58.0 Someone updating from an older minor version will get the mobile CTA: https://www.mozilla.org/en-US/firefox/59.0.1/whatsnew/?oldversion=59.0
Liz - wanted to be sure you saw this request. We want to show the previous mobile CTA content in the /whatsnew page in subsequent 'dot' releases
Flags: needinfo?(lhenry)
Marking this as blocking any (desktop) dot releases for 59.
Flags: needinfo?(lhenry)
We can use the almost same as we had in Firefox-59.0-build5, just update the 59.0 to 59.0.1 in the two URLs, and remove the "version < 59.0" restriction so that we catch 59.0 -> 59.0.1 updates with the mobile CTA content. The page content appears to switch on the value of %OLD_VERSION%. "updateLine": [ { "fields": { "detailsURL": "https://www.mozilla.org/%LOCALE%/firefox/59.0.1/releasenotes/", "type": "minor" }, "for": {} }, { "fields": { "actions": "showURL", "openURL": "https://www.mozilla.org/%LOCALE%/firefox/59.0.1/whatsnew/?oldversion=%OLD_VERSION%" }, "for": { "channels": [ "release", "release-localtest", "release-cdntest" ], "locales": [ "an", "bg", "bs", "cak", "cs", "cy", "da", "de", "dsb", "en-US", "eo", "es-AR", "es-CL", "es-ES", "es-MX", "et", "fa", "fi", "fr", "fy-NL", "gu-IN", "hsb", "hu", "hy-AM", "it", "ja", "ja-JP-mac", "ka", "ms", "nb-NO", "nl", "nn-NO", "pl", "pt-BR", "pt-PT", "ru", "sk", "sl", "sq", "sv-SE", "tr", "uk", "zh-CN", "zh-TW" ] } } ]
(In reply to Eric Renaud from comment #1) > Amending that list after discussing w. agibson. This needs to accord the > locales we've established in 1438653#c15 > > an, bg, bs, cak, cs, cy, da, de, dsb, en-US, eo, es-AR, es-CL, es-ES, es-MX, > et, fa, fi, fr, fy-NL, gu-IN, hsb, hu, hy-AM, it, ja, ja-JP-mac, ka, ms, > nb-NO, nl, nn-NO, pl, pt-BR, pt-PT, ru, sk, sl, sq, sv-SE, tr, uk, zh-CN, > zh-TW > > To confirm the functionality: > > Someone updating from an older major version will get the FxA form: > https://www.mozilla.org/en-US/firefox/59.0/whatsnew/?oldversion=58.0 > > Someone updating from an older minor version will get the mobile CTA: > https://www.mozilla.org/en-US/firefox/59.0.1/whatsnew/?oldversion=59.0 Just to be 100% clear, it sounds like you're saying that: Users on of the 44 locales in the quoted comment, and coming from <59.0, should receive https://www.mozilla.org/%LOCALE%/firefox/59.0/whatsnew/?oldversion=58.0 Users on one of the 74 locales in comment #0, and coming from 59.0, should receive https://www.mozilla.org/%LOCALE%/firefox/59.0.1/whatsnew/?oldversion=59.0 Is that correct?
Flags: needinfo?(erenaud)
(In reply to Ben Hearsum (:bhearsum) from comment #5) > (In reply to Eric Renaud from comment #1) > > Amending that list after discussing w. agibson. This needs to accord the > > locales we've established in 1438653#c15 > > > > an, bg, bs, cak, cs, cy, da, de, dsb, en-US, eo, es-AR, es-CL, es-ES, es-MX, > > et, fa, fi, fr, fy-NL, gu-IN, hsb, hu, hy-AM, it, ja, ja-JP-mac, ka, ms, > > nb-NO, nl, nn-NO, pl, pt-BR, pt-PT, ru, sk, sl, sq, sv-SE, tr, uk, zh-CN, > > zh-TW > > > > To confirm the functionality: > > > > Someone updating from an older major version will get the FxA form: > > https://www.mozilla.org/en-US/firefox/59.0/whatsnew/?oldversion=58.0 > > > > Someone updating from an older minor version will get the mobile CTA: > > https://www.mozilla.org/en-US/firefox/59.0.1/whatsnew/?oldversion=59.0 > > Just to be 100% clear, it sounds like you're saying that: > Users on of the 44 locales in the quoted comment, and coming from <59.0, > should receive > https://www.mozilla.org/%LOCALE%/firefox/59.0/whatsnew/?oldversion=58.0 > > Users on one of the 74 locales in comment #0, and coming from 59.0, should > receive > https://www.mozilla.org/%LOCALE%/firefox/59.0.1/whatsnew/?oldversion=59.0 > > Is that correct? I spoke with Eric about this on Slack: erenaud [10:48 AM] Would it be acceptable to keep the same conditions as with the 59.0 /whatsnew? bhearsum [10:51 AM] Yeah, that's totally fine. That means that the same ~44 locales get the same WNP, for users coming from versions <59.0? And any user (regardless of locale) coming 59.0 gets no WNP? erenaud [10:54 AM] Acceptable, yes. I’ve no doubt there will be another dot release that will afford us more time.
Flags: needinfo?(erenaud)
Slack: 13:52 <aki> are there any new contraints for the 59.0.2 wnp? or should i follow what 59.0.1 did? 13:53 <erenaud> Verbatim to 59.0.1 would be grand, thank you for checking. 13:53 <aki> got it, thank you! Downloaded the 59.0.1 blob and copied the 2nd entry from the updateLine, and s,59.0.1,59.0.2,
Current status - 59.0.2 has shipped, and the update server is configured to show the WNP page for updates starting below 59.0, which is a little different from the request. We (RelEng) don't think it would difficult to also show WNP from 59.0 and 59.0.1, if that is still wanted.
(In reply to Nick Thomas [:nthomas] (UTC+13) from comment #8) > Current status - 59.0.2 has shipped, and the update server is configured to > show the WNP page for updates starting below 59.0, which is a little > different from the request. We (RelEng) don't think it would difficult to > also show WNP from 59.0 and 59.0.1, if that is still wanted. That would definitely be a win in future releases, showing the WNP to users coming from both .0 and .0.x Should I ask for that config to be drafted now or simply with the next request to show the WNP?
Flags: needinfo?(nthomas)
At this point we may as well implement for 60.0. It would be helpful if the request could specify url, locales, and prior versions for each behaviour. eg: 1, url: https://www.mozilla.org/%LOCALE%/firefox/60.0.1/whatsnew/?oldversion=%OLD_VERSION% locales: ab-CD, ef-GH, ... version: < 60.0 2, url: https://www.mozilla.org/%LOCALE%/firefox/60.0.1/whatsnew/?oldversion=%OLD_VERSION% locales: zy-XW, ab-CD, ... version: >= 60.0 AIUI from the early comments on this bug the url doesn't change because bedrock is switching based on %OLD_VERSION% provided by the client. RelEng would need to bump the 60.0.1 part as point releases came along. %LOCALE% is expanded by the update server before it responds to the client.
Flags: needinfo?(nthomas)
(In reply to Nick Thomas [:nthomas] (UTC+12) from comment #10) > At this point we may as well implement for 60.0. I think that's bug 1455010 .
We're past the point of doing anything for 59 at this point.
59.0.3 was shipped to windows only, and had the WNP set up the same as 59.0.2. Lets mark this FIXED.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
The WNP setup for 60.0 / 60.0.1 is in bug 1455010.
You need to log in before you can comment on or make changes to this bug.