Closed Bug 1399849 Opened 7 years ago Closed 6 years ago

Set up whatsnew pages for 57.0b4 devedition

Categories

(Release Engineering :: Release Requests, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: catlee, Assigned: nthomas)

References

Details

These should be displayed for users coming from 56 devedition.

Url should be something like /firefox/%VERSION%a2/whatsnew/
Assignee: nobody → kmoir
Depends on: 1399276
Doesn't the release blob for devedition 57.0b1 need to be in balrog before we can create a what's new page for it?

https://wiki.mozilla.org/Release:Release_Automation_on_Mercurial:Updates_through_Shipping#Set-up_whatsnew_page
Flags: needinfo?(catlee)
Yup. We just need to make sure this is ready before we serve updates to b1.
Flags: needinfo?(catlee)
After meeting with the developer marketing team, it looks like we don't need this for b1. Right now they're targeting b3 for having a whatsnew page for DE.

Will update this bug once we know for sure.
Summary: Set up whatsnew pages for 57.0 devedition → Set up whatsnew pages for 57.0b3 devedition
created releases/FUTURE/devedition-devedition-57.0b3.json so we won't forget when b3 arrives
the marketing team won't be ready for b3. we'll check in again before b4.
Summary: Set up whatsnew pages for 57.0b3 devedition → Set up whatsnew pages for 57.0b4 devedition
Hello - the dev ed /whatsnew and /firstrun pages have been r+ed and will be live before the b4. 

So, specific to this bug, we're requesting /firefox/%VERSION%a2/whatsnew/ be pointed to in the release/rolled in at runtime.
Flags: needinfo?(catlee)
add actions and openURL to the deved 57.0b4 blob
5:45 PM presumably "openURL": "https://www.mozilla.org/%LOCALE%/firefox/56.0/whatsnew/?oldversion=%OLD_VERSION%",
5:45 PM becomes   "openURL": "https://www.mozilla.org/%LOCALE%/firefox/57.0a2/whatsnew/",
WNP is set up for 57.0b4 build1, as an update to the Devedition-57.0b4-build1 release in Balrog so that we don't need any manual work at the point of pushing updates to aurora (ps ignores our convention of using a -WNP suffix for WNP-enabled blobs).

Release Data for Devedition-57.0b4-build1

--- Data Version 1427
+++ Data Version 1428
@@ -1,4 +1,5 @@
 {
+  "actions": "showURL",
   "appVersion": "57.0",
   "detailsUrl": "https://www.mozilla.org/%LOCALE%/firefox/57.0/releasenotes/",
   "displayVersion": "57.0 Beta 4",
@@ -26,6 +27,7 @@
   },
   "hashFunction": "sha512",
   "name": "Devedition-57.0b4-build1",
+  "openURL": "https://www.mozilla.org/%LOCALE%/firefox/57.0a2/whatsnew/",
   "platformVersion": "57.0",
   "platforms": {
     "Darwin_x86-gcc3": {

We'll need to repeat this for any extra builds we do for 57.0b4.

The firstrun situation is taken care of by https://hg.mozilla.org/releases/mozilla-beta/file/1c3b6791f9433c7cf8d6ecb453c9277fd99a5b4a/browser/branding/aurora/pref/firefox-branding.js#l8
Flags: needinfo?(catlee)
We didn't ship b4.  b5 has now beet set up with the what's new page
(In reply to Simon Fraser [:sfraser] ⌚️GMT from comment #9)
For the record, :jcristau, :bhearsum and :sfraser in #releaseduty discovered updates from 57.0bX to 57.0b5 don't show the WNP. Versions <56 do.

It turns out the client ignores what Balrog exposes if the version number doesn't change. More precisely, Julien pointed out [1]: browser.startup.homepage_override.mstone is set to "57.0" (with no beta number). Ben said this behavior have been here for years. As a consequence, we can't display WNP updates in the middle of nighlies or betas.

This may need a follow up fix, if this turns out to be a hard requirement from Marketing. What do you think, Eric?

[1] http://searchfox.org/mozilla-central/rev/a4702203522745baff21e519035b6c946b7d710d/browser/components/nsBrowserContentHandler.js#102
Flags: needinfo?(erenaud)
Johan, I discussed with Arcadio on the TL&I (aka Developer Marketing team) - we wanted to be sure we presented the case to justify the work request for this fix in Balrog - 

The exposure almost goes without saying, with these pages being seen with fresh installs and/or updates of Dev Edition.  We hypothesize that revival of these onboarding pages will lead to higher retention by way of providing developers the content/links they need to use devtools. With 3 downloads as the 'known' to convert a dev into a Monthly Active User, every chance we get to promote the value of devtools follows the path of promoting regular downloads of DE (and MAU).
Flags: needinfo?(jlorenzo)
Flags: needinfo?(erenaud)
Flags: needinfo?(alainez)
If I understand comment 11 correctly, it seems new WNP are planned for the next cycles, at least in order to validate that the retention rate gets higher.

:rstrong, is there anything anything we can do regarding comment 10?
Flags: needinfo?(jlorenzo) → needinfo?(robert.strong.bugs)
Hi Johan, the code that handles this is outside of app update... specifically it is in this file
https://dxr.mozilla.org/mozilla-central/source/browser/components/nsBrowserContentHandler.js

If you want this behavior changed dolske or one of the other Firefox desktop engineer managers should be able to provide assistance.
Flags: needinfo?(robert.strong.bugs) → needinfo?(dolske)
(In reply to Eric Renaud from comment #11)
> Johan, I discussed with Arcadio on the TL&I (aka Developer Marketing team) -
> we wanted to be sure we presented the case to justify the work request for
> this fix in Balrog - 
> 
> The exposure almost goes without saying, with these pages being seen with
> fresh installs and/or updates of Dev Edition.  We hypothesize that revival
> of these onboarding pages will lead to higher retention by way of providing
> developers the content/links they need to use devtools. With 3 downloads as
> the 'known' to convert a dev into a Monthly Active User, every chance we get
> to promote the value of devtools follows the path of promoting regular
> downloads of DE (and MAU).

Additionally, we're the /whatsnew and /firstrun pages to deliver the resources a developer needs to make the most of Developer Edition. Resources like documentation, links to Github for contribution and Discourse for feedback and an email capture for a ongoing series of Developer Edition specific emails to help with retention. Also, we're on the path to start promoting Developer Edition as "the best Firefox for developers" and the onboarding experiences should be available to every download or update we generate as a way of improving retention.
Flags: needinfo?(alainez)
Talked about this with Sam, over to him.
Flags: needinfo?(dolske)
Thanks Dolske.Do we have a path to resolving this now? I've noticed this is getting ping pong'd. As we getting ready to ramp up or marketing muscle to promote Developer Edition downloads, the onboarding pages are more important than ever, as stated above. 

Wondering if I can schedule a quick meeting with the stakeholders here to see if we can expedite the request. 

Please let me know.

Thanks!
Flags: needinfo?(dolske)
I talked with dolske about moving this forward. I gather from comment #11 the intention is that this devedition what's new page will be maintained and updated 57 and up? That suggests landing changes in mozilla-central and doing an uplift to beta to make this available for the next devedition release. If we are committed to maintaining relevant content on this page for each release going forward, this seems like a great idea. 

I'll look into what's needed on the Firefox side. :alainez, let me know if you want me to join a meeting, you can find me as sfoster on IRC / (#fx-team, #developers).
Flags: needinfo?(dolske)
Can I clarify what the 'a2' in /firefox/%VERSION%a2/whatsnew/ represents? Is that some token we want to pull out of the buildid or milestone, or just a literal 'a2' we should hard-code in there that will work for current and future releases. Chris?

Also, Johan, I'm not clear on what you are asking for in comment #10 - how would that logic work? As you say, and upgrade from 57b1 to 57b4 or whatever won't trigger loading the whatsnew content at startup. Only a major version upgrade i.e. 56 to 57. If we *do* want any 57 users on a current beta to see this content after upgrading to our next beta release, we'll likely need a new pref.
Flags: needinfo?(jlorenzo)
Flags: needinfo?(catlee)
(In reply to Sam Foster [:sfoster] from comment #18)
> Can I clarify what the 'a2' in /firefox/%VERSION%a2/whatsnew/ represents? Is
> that some token we want to pull out of the buildid or milestone, or just a
> literal 'a2' we should hard-code in there that will work for current and
> future releases. Chris?

The 'a2' is carry-over from when devedition was the same as the aurora channel builds. AIUI, bedrock already has support for treating version numbers with an 'a2' suffix as the developer edition builds. This should continue to work for the current and future releases. We could also change it to some other string, but that would require changes on the bedrock side.
Flags: needinfo?(catlee)
(In reply to Sam Foster [:sfoster] from comment #18)
> Also, Johan, I'm not clear on what you are asking for in comment #10 - how
> would that logic work? [...] If we *do* want any 57 users on a current beta to see
> this content after upgrading to our next beta release, we'll likely need a
> new pref.

I don't know too much about the client logic that determines whether a WNP should be displayed. I agree, it sounds like  "browser.startup.homepage_override.mstone" is used for another purpose. Hence a new pref may be better. I can tell for sure, changing the pref won't impact Balrog (the update server). As a consequence, I don't have any preferences about the implementation.

I hope I have answered your question, Sam. If not, please let me know.
Flags: needinfo?(jlorenzo)
I think the conversation about allowing whatsnew pages outside of version bumps should go in a separate bug, not tied to release engineering, and not tied to 57.
Bug 1408209 has landed the ability for devedition to load the what's new page when we bump the (major) version. This should ride the trains so as devedition users get the 58 upgrade, they will see the new what's new page. 

This does not directly address the request for 57.0b*. As pointed out here in comment #21, as well as in https://bugzilla.mozilla.org/show_bug.cgi?id=1408209#c5 this has problems that warrant their own discussion outside of release engineering - if there is still product & marketing interest in making that happen.
To summarise
* Users who updated to DevEd 57.0b1, b2, or b3 didn't get a WNP (it wasn't ready)
* 57.0b4 didn't ship to users
* Releng has customized the update server for 57.0b5 though b11, so that anyone updating from 56 or older gets the WNP
* bug 1408209 fixes 58.0 - the first update a DevEd user gets to a 58.0 based build will show the WNP. This is the same as how Nightly works

I agree with the second paragraph in comment #22, with the addendum that the update server cannot distinguish between users which updated to 57.0b1-b3 vs b5-b11. Time for RESOLVED FIXED ?
From a marketing perspective, we're not looking for updates on .releases. Having the onboarding pages show up to first time downloads and for version updates based on Firefox release dates drives our objective: give developers the information they need to continue using Developer Edition. 

Please let me know if there is anything I can do to help unblock this and I'm looking forward to /whatsnew and /firstrun pages on with Firefox Quantum and Developer Edition 58.
I'm going to follow up on this via email/meeting to make sure are all on the same page.
Assignee: kmoir → nthomas
Bulk change of QA Contact to :jlund, per https://bugzilla.mozilla.org/show_bug.cgi?id=1428483
QA Contact: catlee → jlund
Haven't heard anything further.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.