1009893 - Show /whatsnew tour URL to users updating to 30.0 and 31.0 (from all past versions of Firefox)

Status: RESOLVED FIXED

(Release Engineering :: Release Requests, defect, P2)

Description

[Holly Habstritt Gaal [:Habber]]

Show /whatsnew tour URL to users updating from pre-29 versions of Firefox. This impacts Firefox 30 release channel.

The whatsnew page with the following URL should be enabled for all locales: 
https://www.mozilla.org/%LOCALE%/firefox/%VERSION%/whatsnew/?oldversion=%OLD_VERSION%

Set this URL: 
https://www.mozilla.org/en-US/firefox/30.0/whatsnew/?oldversion=28.0



This ensures that users who skipped the 29 launch will still see the Firefox onboarding tour. Users who did update during the 29 launch (or 29+) will not see this tour a second time. 

As a result, we can also be sure that ESR versions will also see /whatsnew upon updating.


(see bug 987480 for past implementation)

Comment 1

[Matthew N. [:MattN]]

To clarify, we want to continue to include the whatsnew in the update snippets for 30 and 31 but not for the offers from 29.*.

Comment 2

[Matthew N. [:MattN]]

One question is whether we still want to show the update to pave-over installations who skip 29.*? I think it will be a much smaller number than 29 since there won't be as much publicity. The in-product homepage URL pref was only landed on 29 so if we want to handle this we need to land bug 987407 on 30 and 31 while sending the "silent" action in the update snippet.

Comment 3

[Nick Thomas [:nthomas] (UTC+12)]

So, for updates:
* Firefox 30 - show whatsnew for 28.0 and older, but not 29.0/29.0.1
* Firefox 31 - show whatsnew for 28.0 and older, but not 29.0/29.0.1/30.0/30.0.x

We don't have any support for automating that at the moment, but can manually do this a la
  https://wiki.mozilla.org/Releases/Firefox_29.0.1/BuildNotes#Modify_snippets

For the paveover case, you'd also want some version detection logic I think. Otherwise 30 paving over 29 will get a whatsnew as well. Perhaps that covers both cases.

Comment 4

[Holly Habstritt Gaal [:Habber]]

(In reply to Nick Thomas [:nthomas] from comment #3)
> So, for updates:
> * Firefox 30 - show whatsnew for 28.0 and older, but not 29.0/29.0.1
> * Firefox 31 - show whatsnew for 28.0 and older, but not
> 29.0/29.0.1/30.0/30.0.x
> 
> We don't have any support for automating that at the moment, but can
> manually do this a la
>   https://wiki.mozilla.org/Releases/Firefox_29.0.1/BuildNotes#Modify_snippets
> 
> For the paveover case, you'd also want some version detection logic I think.
> Otherwise 30 paving over 29 will get a whatsnew as well. Perhaps that covers
> both cases.

Hi Nick, 
Your logic is correct. I also confirmed this with Jen Bertsch. Do not show whatsnew to users updating from 29+ to 30-31. We will address turning it back on for upcoming versions when appropriate.

Comment 5

[Nick Thomas [:nthomas] (UTC+12)]

Ben, we could probably modify the patcher config to something like this (in the <current-update> block):
    <actions>
        <action>
            actions   showURL
            openURL   http://foo
            versions  10.0 10.0.1 ... 28.0
        </action>
        <action>
            actions   silent
            versions  29.0 29.0.1 30.0
        </action>
    </actions>
and teach the snippet generator to handle that. Bonus points for allowing control on 'locales' in each action too (eg only whatsnew for pl locale a while back). Alternatively, leave as-is in <current-update> and allow overrides in blocks like <28.0>. Any opinions on that re return on time investment vs manual hackery until Balrog.

Comment 6

[Nick Thomas [:nthomas] (UTC+12)]

Never mind the second idea, it doesn't work so well when you want to override in a newly created release (eg 30.0 here). You'd have to plumb it into the patcher config bumper and all the way back to the release config.

Comment 7

[Nick Thomas [:nthomas] (UTC+12)]

(In reply to Matthew N. [:MattN] from comment #2)
> One question is whether we still want to show the update to pave-over
> installations who skip 29.*? I think it will be a much smaller number than
> 29 since there won't be as much publicity. The in-product homepage URL pref
> was only landed on 29 so if we want to handle this we need to land bug
> 987407 on 30 and 31 while sending the "silent" action in the update snippet.

What do you want to do here ? If we were to add version-detection logic to nsBrowserContentHandler.js then we'd not need anything on the updates side. We'd just make sure to not say 'actions  silent' and fall back to startup.homepage_override_url.

Comment 8

[Matthew N. [:MattN]]

(In reply to Nick Thomas [:nthomas] from comment #3)
> For the paveover case, you'd also want some version detection logic I think.
> Otherwise 30 paving over 29 will get a whatsnew as well. Perhaps that covers
> both cases.

I'd rather not add new untested version detection logic for a small portion of the user base for one-time use but I asked the question as I was hoping someone else would make the call :)

Comment 9

[Holly Habstritt Gaal [:Habber]]

Apologies for altering the logic since work has already started, but I received a new request from the PMM team. 

We need to turn on Whatsnew for *all* users updating to 30 and 31. We no longer need a special case for those updating from 28.0 and older. We will do some conditional work on the web side to display appropriate content. 

We are still reliant on Firefox passing through the ?oldversion parameter in the URL. Confirming with :agibson tomorrow, but as long as we have this, we will be able to have enough control from the web to show the conditional content we need.

Comment 10

[Matthew N. [:MattN]]

(In reply to Holly Habstritt Gaal [:Habber] from comment #9)
> We need to turn on Whatsnew for *all* users updating to 30 and 31. We no
> longer need a special case for those updating from 28.0 and older. We will
> do some conditional work on the web side to display appropriate content. 

I can't say I'm a fan of showing another whatsnew page just a few weeks after some users see the 29.0 one. I guess we must have a really good reason that outweighs the fatigue on users though I wonder why it can't wait a release or two to reduce the fatigue issue.

> We are still reliant on Firefox passing through the ?oldversion parameter in
> the URL. Confirming with :agibson tomorrow, but as long as we have this, we
> will be able to have enough control from the web to show the conditional
> content we need.

FYI: ?oldversion should always appear for whatsnew URLs. The one time it didn't was my fault.

Comment 11

[Holly Habstritt Gaal [:Habber]]

Although whatsnew will still be turned on, the tour will not show for users updating from 29+. We'll use ?oldversion to be sure the tour info panel displays only for users updating from 28.0 and older. Others will see the post-tour web page only. We don't want to interrupt users with a tour that have already seen it.

I agree that we should be selective about when we show whatsnew to users and not show it after every update. From what I understand, there will be an effort after 31 to do this. Until then, Sync is still considered new and will be displayed on the /whatsnew URL. Jen, can you give more detail here?

Comment 12

[Jennifer Bertsch [:jbertsch]]

Hi MattN-

We (Engagement) absolutely share your concern about not showing the whatsnew page too frequently if we don't have anything important to say.

However, we think the message about Sync, which is what we'll show to folks updating to 30 and 31 from 29+ is very important.  We'll also measure how users interact with that page for 30 and make content changes on our end for 31 if necessary.

Thx,
Jen

Comment 13

[Holly Habstritt Gaal [:Habber]]

(In reply to Matthew N. [:MattN] from comment #10)
> (In reply to Holly Habstritt Gaal [:Habber] from comment #9)
> > We need to turn on Whatsnew for *all* users updating to 30 and 31. We no
> > longer need a special case for those updating from 28.0 and older. We will
> > do some conditional work on the web side to display appropriate content. 
> 
> I can't say I'm a fan of showing another whatsnew page just a few weeks
> after some users see the 29.0 one. I guess we must have a really good reason
> that outweighs the fatigue on users though I wonder why it can't wait a
> release or two to reduce the fatigue issue.
> 
> > We are still reliant on Firefox passing through the ?oldversion parameter in
> > the URL. Confirming with :agibson tomorrow, but as long as we have this, we
> > will be able to have enough control from the web to show the conditional
> > content we need.
> 
> FYI: ?oldversion should always appear for whatsnew URLs. The one time it
> didn't was my fault.


In case it isn't clear, I should clarify that we don't need to show whatsnew for minor updates, only for updates to 30.0 and 31.0.

Comment 14

[Sylvestre Ledru [:Sylvestre]]

Jen, I think it is also important to keep in mind the use case of ESR (24 => 31).

Comment 15

[Jennifer Bertsch [:jbertsch]]

Hi Sylvestre-

ESR should be covered by the logic we're talking about here and will see the tour.

Thx,
Jen

Comment 16

[Nick Thomas [:nthomas] (UTC+12)]

(In reply to Holly Habstritt Gaal [:Habber] from comment #13)
> In case it isn't clear, I should clarify that we don't need to show whatsnew
> for minor updates, only for updates to 30.0 and 31.0.

To fully spec that, did you mean
* ship 30.0   - all updates from old -> 30.0 get whatsnew  
* ship 30.0.1 - no whatsnew on 30.0 -> 30.0.1, otherwise old -> 30.0.1 gets one
* ship 30.0.2 - no whatsnew on 30.0/30.0.1 -> 30.0.2, otherwise old -> 30.0.2 gets one
* repeat for other 30.0.x/31.0/31.0.x
* ship 32.0   - no whatsnew for any updates

Please note: ESR31 is handled separately, and we'll need to be careful not to lose the whatsnew request at 31.2.0, when ESR24 releases are first offered ESR31. Given ESR is meant for enterprises, it may not be an important case to cover.

Comment 17

[Holly Habstritt Gaal [:Habber]]

(In reply to Nick Thomas [:nthomas] from comment #16)
> (In reply to Holly Habstritt Gaal [:Habber] from comment #13)
> > In case it isn't clear, I should clarify that we don't need to show whatsnew
> > for minor updates, only for updates to 30.0 and 31.0.
> 
> To fully spec that, did you mean
> * ship 30.0   - all updates from old -> 30.0 get whatsnew  
> * ship 30.0.1 - no whatsnew on 30.0 -> 30.0.1, otherwise old -> 30.0.1 gets
> one
> * ship 30.0.2 - no whatsnew on 30.0/30.0.1 -> 30.0.2, otherwise old ->
> 30.0.2 gets one
> * repeat for other 30.0.x/31.0/31.0.x
> * ship 32.0   - no whatsnew for any updates
> 
> Please note: ESR31 is handled separately, and we'll need to be careful not
> to lose the whatsnew request at 31.2.0, when ESR24 releases are first
> offered ESR31. Given ESR is meant for enterprises, it may not be an
> important case to cover.

You are correct for 30 and 31. Thanks for clarifying the "otherwise old" case. For 32, we will not yet define what happens w/ whatsnew.  

Though a smaller audience, it would be valuable to show whatsnew to users updating from ESR24 because they are updating to the new Australis design. If it's possible to handle this separately and it isn't too difficult, please allow whatsnew to be shown for ESR24>ESR31 at 31.2.0.

Comment 18

[[e-mail] (:bhearsum)]

(In reply to Nick Thomas [:nthomas] from comment #5)
> Ben, we could probably modify the patcher config to something like this (in
> the <current-update> block):
>     <actions>
>         <action>
>             actions   showURL
>             openURL   http://foo
>             versions  10.0 10.0.1 ... 28.0
>         </action>
>         <action>
>             actions   silent
>             versions  29.0 29.0.1 30.0
>         </action>
>     </actions>
> and teach the snippet generator to handle that. Bonus points for allowing
> control on 'locales' in each action too (eg only whatsnew for pl locale a
> while back). Alternatively, leave as-is in <current-update> and allow
> overrides in blocks like <28.0>. Any opinions on that re return on time
> investment vs manual hackery until Balrog.

Given how actively we're working on Balrog, I'm inclined to say manually hackery. I'm willing to pitch in to automated it now if you are, though.

Comment 19

[Lukas Blakk [:lsblakk] use ?needinfo]

Making sure this is on Tracy & Kairo's radar for testing on the final RC 30.

Comment 20

[Robert Kaiser]

Leaving this to tracy to make sure testing is happening, but I'll keep it in mind.

Comment 21

[Tracy Walker [:tracy]]

before I proceed further on other platforms, this is what I saw on Mac with 28.0b9 on beta channel

28.0b9 updates to 29.0.1 (showed tour) updates to 30.0b8 (showed tour) 

From what I understand, because of one of the p2o bugs, we have been forced to funnel all old updates through Fx29. That's what I observed in the above update path. So going forward, "otherwise old" >= 29.0.1 Is that correct, Ben? 

using the above build at 30.0b8, change update channel to aurora, then it updates to 31.0a2 Aurora (no tour shown)

Comment 22

[[e-mail] (:bhearsum)]

(In reply to [:tracy] Tracy Walker - QA Mentor from comment #21)
> before I proceed further on other platforms, this is what I saw on Mac with
> 28.0b9 on beta channel
> 
> 28.0b9 updates to 29.0.1 (showed tour) updates to 30.0b8 (showed tour) 
> 
> From what I understand, because of one of the p2o bugs, we have been forced
> to funnel all old updates through Fx29.

We do have to funnel updates through 29, but it's not because of a pwn2own bug. bug 908134 has details on that, but they're probably not relevant here.

> That's what I observed in the above
> update path. So going forward, "otherwise old" >= 29.0.1 Is that correct,
> Ben? 

That's right. Versions older than 29 must update to 29.0 before proceeding further. (There's an even older watershed point around 10.0/11.0, but you probably don't care about that.)

> using the above build at 30.0b8, change update channel to aurora, then it
> updates to 31.0a2 Aurora (no tour shown)

AFAIK whatsnew is never enabled for Aurora, so this doesn't surprise me.

Comment 23

[Tracy Walker [:tracy]]

ok, clearing needinfo me, adding [qa+] and taking QA contact to keep it on my radar going forward.

Comment 24

[Robert Kaiser]

(In reply to Ben Hearsum [:bhearsum] from comment #22)
> That's right. Versions older than 29 must update to 29.0 before proceeding
> further.

Doesn't that mean that the case to be covered in this bug is actually never hit (i.e. nobody updates directly from a pre-29 version to 30 or 31)?

Comment 25

[Matthew N. [:MattN]]

See comment 24

Comment 26

[Nick Thomas [:nthomas] (UTC+12)]

I'm confused by what Tracy found. The expected paths on the __beta__ channel are:
  29.0b1 or higher  -->  latest               (includes 29.0, 29.0.1; not opening a whatsnew page)
  28.0b or older    -->  29.0b8  --> latest   (opening a whatsnew afterwards)
with no stop offs in 29.0 or 29.0.1, and latest is currently 30.0b8 (but not for long). NB: that installing 29.0 or 29.0.1 will show a whatsnew page, that's from an in-app preference.

On the release channel, everything from 10 upwards point to 29.0.1, with a whatsnew.

Given we want to show a whatsnew page for 30.0 (comment #9) we only need a version bump in the URL we're already using. I'm going to look at a little automation to make sure that keeps up to date automatically.

Comment 27

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: [tools] Bump openURL if it's present

We have to specify this up front in the snippet, there's no interpolation done by AUS2, or by the client (except %OLD_VERSION%). I've tested this taking the 29.0 patcher config and bumping it, and the only difference is
-            openURL   https://www.mozilla.org/%locale%/firefox/29.0/whatse...
+            openURL   https://www.mozilla.org/%locale%/firefox/29.0.1/what...

Comment 28

[[e-mail] (:bhearsum)]

Comment on attachment 8431328 [details] [diff] [review]
[tools] Bump openURL if it's present

Review of attachment 8431328 [details] [diff] [review]:
-----------------------------------------------------------------

::: lib/perl/Release/Patcher/Config.pm
@@ +164,5 @@
> +    $newURL =~ s/$oldVersion/$version/;
> +
> +    return $newURL;
> +}
> +

New Perl code, my eyes are burning!

Comment 29

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 8431328 [details] [diff] [review]
[tools] Bump openURL if it's present

Sorry 'bout that.

https://hg.mozilla.org/build/tools/rev/1a8648bb6e70

Comment 30

[Nick Thomas [:nthomas] (UTC+12)]

At this point we are ready for 30.0 and 31.0; the oldversion parameter is present the same as 29.0 (comment #9). It would be best to have a new bug if we want to change at 32.0.

RelEng will have to manually handle the special cases for any 30.0.x or 31.0.x (comment #16). It would be good if we could add some QA process, or even a reminder to release-drivers from website people, so that we don't miss it in a chemspill rush. 

Clearing the ni? on gavin since it refers to the initial, more complicated, situation. FTR, paveover installs won't show the whatsnew page but updates will.

Comment 31

[Nick Thomas [:nthomas] (UTC+12)]

(In reply to Holly Habstritt Gaal [:Habber] from comment #17)
> Though a smaller audience, it would be valuable to show whatsnew to users
> updating from ESR24 because they are updating to the new Australis design.
> If it's possible to handle this separately and it isn't too difficult,
> please allow whatsnew to be shown for ESR24>ESR31 at 31.2.0.

This is hard to capture as it's still 3 release cycles off. I've filed bug 1018694 for it but lets try to talk again closer to then.

Comment 32

[Nick Thomas [:nthomas] (UTC+12)]

I landed a followup fix - http://hg.mozilla.org/build/tools/pushloghtml?changeset=ff7679203195
The automation change didn't work because the url was stale (29.0 instead of 29.0.1), should be good next time.