644114 - Add ability for AUS to serve different updates for background and manual checks

Status: RESOLVED INCOMPLETE

(AUS Graveyard :: General, defect)

Description

[Robert Strong (they/them - no direct email)]

There have been times like now when there is a major (Firefox 4.0) and a minor update (Firefox 3.6.16) available and people expect to get 4.0 when they do a manual check. Since app update sends force=1 for manual update checks it should be possible to make it so AUS offers Firefox 4.0 for a manual check and Firefox 3.6.16 for a background check for example.

Comment 1

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

In principle it's possible, but in practice it would likely be a mess and I wouldn't like to attempt it in AUS2. For example, suppose we do a new 3.6.x and QA needs to test updates from 3.6.older. They go Help > Check for Updates and get a major update to 4.0.latest instead. Would we use this type of functionality in a world of silent updates, where presumably everyone gets a background major update as progress is made.

Also implicit is a requirement we QA the most popular (or all) 3.6.x -> 4.0 paths, instead of 3.6.latest -> 4.0. I'd love if we could offer more direct paths to the latest build, but we keep banging into this issue.

Comment 2

[Robert Strong (they/them - no direct email)]

(In reply to comment #1)
> In principle it's possible, but in practice it would likely be a mess and I
> wouldn't like to attempt it in AUS2. For example, suppose we do a new 3.6.x and
> QA needs to test updates from 3.6.older. They go Help > Check for Updates and
> get a major update to 4.0.latest instead.
A single line of code pasted in the error console can perform a background check to get the minor update.

> Would we use this type of
> functionality in a world of silent updates, where presumably everyone gets a
> background major update as progress is made.
There will still be the ability to perform manual checks even with silent updates. Silent updates will use the exact same mechanism we have today to get the update. Also, the new update snippet format can specify whether or not the update requires user consent.

> Also implicit is a requirement we QA the most popular (or all) 3.6.x -> 4.0
> paths, instead of 3.6.latest -> 4.0. I'd love if we could offer more direct
> paths to the latest build, but we keep banging into this issue.
This isn't about providing the ability for all of 3.6.x to upgrade to 4.0. It is about making it so background updates would go to the latest 3.6.x and the 3.6.x that has already been QA'd to go to 4.0 would be offered for manual update checks.

Comment 3

[Robert Strong (they/them - no direct email)]

(In reply to comment #2)
>...
> > Also implicit is a requirement we QA the most popular (or all) 3.6.x -> 4.0
> > paths, instead of 3.6.latest -> 4.0. I'd love if we could offer more direct
> > paths to the latest build, but we keep banging into this issue.
> This isn't about providing the ability for all of 3.6.x to upgrade to 4.0. It
> is about making it so background updates would go to the latest 3.6.x and the
> 3.6.x that has already been QA'd to go to 4.0 would be offered for manual
> update checks.
note that the above is more of a process / policy decision related and is secondary to the functionality and the point being that the QA issue wouldn't be an issue for manual checks for 3.6.15 to go to 4.0 since that has been QA'd.

Comment 4

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

(In reply to comment #2)
o 4.0.latest instead.
> A single line of code pasted in the error console can perform a background
> check to get the minor update.

Ooh, didn't realise that. What's the magical incantation ?
 
> This isn't about providing the ability for all of 3.6.x to upgrade to 4.0. It
> is about making it so background updates would go to the latest 3.6.x and the
> 3.6.x that has already been QA'd to go to 4.0 would be offered for manual
> update checks.

Are you talking specifically about what we did on 4.0 release day, when we happened to have both 3.6.15 -> 4.0 and 3.6.16 -> 4.0 QA'd ? Otherwise I must be missing something, as there's only a minor update if the user is behind on 3.6.x, and there's only a major update if they're up to date.

Comment 5

[Robert Strong (they/them - no direct email)]

(In reply to comment #4)
> (In reply to comment #2)
> o 4.0.latest instead.
> > A single line of code pasted in the error console can perform a background
> > check to get the minor update.
> 
> Ooh, didn't realise that. What's the magical incantation ?
const Ci = Components.interfaces; const Cc = Components.classes; Cc["@mozilla.org/updates/update-service;1"].getService(Ci.nsIApplicationUpdateService).QueryInterface(Ci.nsITimerCallback).notify(null);

> 
> > This isn't about providing the ability for all of 3.6.x to upgrade to 4.0. It
> > is about making it so background updates would go to the latest 3.6.x and the
> > 3.6.x that has already been QA'd to go to 4.0 would be offered for manual
> > update checks.
> 
> Are you talking specifically about what we did on 4.0 release day, when we
> happened to have both 3.6.15 -> 4.0 and 3.6.16 -> 4.0 QA'd ? Otherwise I must
> be missing something, as there's only a minor update if the user is behind on
> 3.6.x, and there's only a major update if they're up to date.
That and that we often release a new minor to both the latest and previous branch(es) at the same time so people end up in the same scenario.

Comment 6

[Takanori MATSUURA]

This bug lies at rest in the graveyard.