[Trailhead] Setup WNP for users coming from <67.0.5 and receiving the 67.0.5 release (actual release number TBD)
Categories
(Release Engineering :: Release Requests, task)
Tracking
(firefox67 fixed, firefox67.0.1blocking fixed, firefox68 unaffected, firefox69 unaffected)
Tracking | Status | |
---|---|---|
firefox67 | --- | fixed |
firefox67.0.1 | blocking | fixed |
firefox68 | --- | unaffected |
firefox69 | --- | unaffected |
People
(Reporter: erenaud, Assigned: nthomas)
References
()
Details
(Whiteboard: [releaseduty])
Attachments
(2 files)
(deleted),
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-release+
|
Details |
(deleted),
text/x-phabricator-request
|
Details |
Request is to have the product point to the /whatsnew page in the Firefox 67.0.5 (corresponding to Trailhead) release and show it (WNP).
- The page will be shown only to en-, de-, and fr-* locales
Schedule:
Deadline for final copy - 5/14
Deadline for final design - 5/14
Coded page on demo for stakeholder QA review - 5/20
WNP 67.0.5 page go live - on or before - 5/21
After a deeper review of https://bugzilla.mozilla.org/show_bug.cgi?id=1547830 I realize that bug is not the request to releng that I thought it was, though this correct bug depends on that one 1547830
Reporter | ||
Updated•6 years ago
|
Reporter | ||
Updated•6 years ago
|
Updated•6 years ago
|
Comment 1•5 years ago
|
||
I believe the desired behavior is…
en/de/fr 66.0 -> 67.0 WNP 67.0
others 66.0 -> 67.0 WNP 67.0
en/de/fr 67.0 -> 67.0.x WNP 67.0.x
others 67.0 -> 67.0.x no page
en/de/fr 66.0 -> 67.0.x WNP 67.0.x
others 66.0 -> 67.0.x WNP 67.0
So the update server needs to omit the showURL/openURL for those upgrading from 67.0 to 67.0.x for non-en/de/fr locales.
Looks like this is what nthomas has implemented in this try https://hg.mozilla.org/try/rev/7a7c4fce7132ee19dec7363c5b2c12ff28cacc41
Assignee | ||
Comment 2•5 years ago
|
||
That's what I was going for. I'm hoping I can generate some steps to test that out, and the in-app change. It's complicated by using different signing in staging releases.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 3•5 years ago
|
||
Assignee | ||
Comment 4•5 years ago
|
||
The patch implements comment 1, which I've reformatted and tweaked the older builds as:
locale version --> new version whatsnew
en/de/fr 67.0 --> 67.0.x WNP-67.0.x
en/de/fr <=66.0.5 --> 67.0.x WNP-67.0.x
others 67.0 --> 67.0.x no page
others <=66.0.5 --> 67.0.x WNP-67.0
where
WNP-67.0 = https://www.mozilla.org/%LOCALE%/firefox/67.0/whatsnew/?oldversion=%OLD_VERSION%
WNP-67.0.x = https://www.mozilla.org/%LOCALE%/firefox/67.0.x/whatsnew/?oldversion=%OLD_VERSION%
and x
is replaced everywhere.
It's unusual to point at .../67.0/whatsnew/... when the app version is higher, but I see non-en/de/fr locale and 67.0.5 will redirect to en-US trailhead content, and we likely don't want to do that. hoosteeno, could you please confirm we are using the correct the urls for the WNP.
We can easily change the WNP config in the update server after we build and ship, we just store the configuration in the gecko tree so that the release automation does the work of setting up in the server.
If we do a 67.0.y after 67.0.x, then we will show WNP-67.0.y to en/de/fr all versions, including 67.0.x. I see the special content is not on .../67.0.6/whatsnew/..., so we might need a further change to hardcode 67.0.5, but can handle that as needed. Handling of the other locales would be unchanged.
Assignee | ||
Comment 5•5 years ago
|
||
Comment on attachment 9067677 [details]
Bug 1551749 - Trailhead WNP, r=tomprince
Beta/Release Uplift Approval Request
- User impact if declined: The what's new page will not be displayed for Trailhead.
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: The usual manual update testing includes checks on the what's new page.
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): We can change the configuration in the update server after the release starts. I've tested the release taskgraph locally and it generates as expected.
- String changes made/needed:
Assignee | ||
Comment 6•5 years ago
|
||
Bedrock are going to make a fix in https://github.com/mozilla/bedrock/issues/7246, so the matrix now looks like
locale version --> new version whatsnew
en/de/fr 67.0 --> 67.0.x WNP-67.0.x
en/de/fr <=66.0.5 --> 67.0.x WNP-67.0.x
others 67.0 --> 67.0.x no page
others <=66.0.5 --> 67.0.x WNP-67.0
where
WNP-67.0 = https://www.mozilla.org/%LOCALE%/firefox/67.0.x/whatsnew/?oldversion=%OLD_VERSION% with 67.0 content
WNP-67.0.x = https://www.mozilla.org/%LOCALE%/firefox/67.0.x/whatsnew/?oldversion=%OLD_VERSION% with Trailhead content
The patch is updated for that and ready to land.
Comment 7•5 years ago
|
||
Comment on attachment 9067677 [details]
Bug 1551749 - Trailhead WNP, r=tomprince
Needed to set the correct WNP URLs for Trailhead locales when we publish the builds to Balrog. Approved for 67.0.1.
Comment 8•5 years ago
|
||
uplift |
Comment 9•5 years ago
|
||
This will show the new whats-new-page to anybody updating from a pre-trailhead
release to a post-trailhead release, but not people updating between
post-trailhead releases.
Comment 11•5 years ago
|
||
bugherder uplift |
Comment 12•5 years ago
|
||
Please specify a root cause for this bug. See :tmaity for more information.
Assignee | ||
Comment 13•5 years ago
|
||
I'm going to change the bug type from defect to task because it was about setting up ahead of the Trailhead release, rather than resolving a problem.
Description
•