Software Update:Major Update Use Cases: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
 
m (Reverted edit of Polo Bluxo, changed back to last version by Sspitzer)
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Major Update Use Cases
'''Major Update Use Cases'''


Let's assume that in each of these cases a Major Update is also available (2.0.0.0):
Let's assume that in each of these cases a Major Update is also available (2.0.0.0):


a) -1 from current minor version (i.e. I have 1.5.0.7 and 1.5.0.8 is published)
a) -1 from current minor version (i.e. I have 1.5.0.7 and 1.5.0.8 is published)
 
Result: User should get the minor update.  No offer of Major will be made
Result: User should get the minor update.  No offer of Major will be made


b) -x from current minor version (i.e. I have 1.5.0.3 and 1.5.0.8 is published)
b) -x from current minor version (i.e. I have 1.5.0.3 and 1.5.0.8 is published)
 
Result: User should get the minor update.  No offer of Major will be made
Result: User should get the minor update.  No offer of Major will be made


c) at current minor version (I have 1.5.0.8 and the only newer version is 2.0.0.0)
c) at current minor version (I have 1.5.0.8 and the only newer version is 2.0.0.0)
 
Result: User should get the offer for major upgrade to 2.0.0.0
Result: User should get the offer for major


d) at current minor version (I have 1.5.0.8 and the only newer version is 2.0.0.0) and have clicked "never" to previous major update offer
d) at current minor version (I have 1.5.0.8 and the only newer version is 2.0.0.0) and have clicked "never" to previous major update offer
 
Result: User should get no update.
Result: User should get no update.


e) at current minor version (I have 1.5.0.8 and the only newer version is 2.0.0.0) and have clicked "never" to previous major update offer - however we've offered a new major version (i.e. 2.1)
e) at current minor version (I have 1.5.0.8 and the only newer version is 2.0.0.0) and have clicked "never" to previous major update offer - however we've offered a new major version (i.e. 2.1)
Result: User should get major update offer to 2.1


Result: User should get major update offer
'''Summary'''


Summary:
The only time I get a major offer is if:


The only time I get a major offer is if:
a) There is no minor update for me (I'm at the latest point release)
AND
b) I've not clicked never for this major update version
    OR
    I've done a manual "Check for Updates..."


a) There is no minor update for me (I'm at the latest point release)
If you do a manual check for updates, we'll clear the per version "never" client side pref for the major update you are presented. This allows the user to "undo" the never decision.
AND
b) I've not clicked never for this major update version OR I've done a manual "Check for Updates..."


Notes:
'''Notes'''


* A never decision does not affect minor updates, only major updates.  (See https://bugzilla.mozilla.org/show_bug.cgi?id=350636 for why this matters.)
* A never decision does not affect minor updates, only major updates.  (See https://bugzilla.mozilla.org/show_bug.cgi?id=350636 for why this matters.)
* If the server side accidentally offered a major update to Fx 1.5.0.7 (and below), it would be bad because the user would get the major update without having agreed to the EULA.  There is nothing in 1.5.0.7 (and below) on the client side to prevent this, so we need a safeguard on the server side.  
* If the server side accidentally offered a major update to Fx 1.5.0.7 (and below), it would be bad because the user would get the major update without having agreed to the EULA.  There is nothing in 1.5.0.7 (and below) on the client side to prevent this, so we need a safeguard on the server side.  
* At some point (Firefox 3, according to bug #341190), we plan to stop supporting Windows 98/ME.
* At some point (Firefox 3, according to bug https://bugzilla.mozilla.org/show_bug.cgi?id=341190), we plan to stop supporting Windows 98/ME. Unlike Fx 1.5.x, Fx 2.0+ sends the OS version as part of the update url when it pings the AUS server.  Again, this is something the server side will take care of, by not presenting incompatible major updates to clients running on unsupported OSes.  See https://bugzilla.mozilla.org/show_bug.cgi?id=341190 for details
Unlike Fx 1.5.x, Fx 2.0+ sends the OS version as part of the update url when it pings the AUS server.  Again, this is something the server side will take care of, by not presenting incompatible major updates to clients running on unsupported OSes.  See https://bugzilla.mozilla.org/show_bug.cgi?id=341190 for details
 
'''Example Table'''


Example table:
Starting point, 1.5.0.7 has shipped.


2.0.0.0 ships
'''When 2.0.0.0 ships, AUS should advertise...'''
1.0 - 1.5.0.6 -> 1.5.0.7 (minor)
1.0 - 1.5.0.6 -> 1.5.0.7 (minor)
1.5.0.7 -> no update (since only 1.5.0.8+ can handle a major update)
1.5.0.7 -> no update (since only 1.5.0.8+ can handle a major update)
2.0.0.0 -> no update
2.0.0.0 -> no update  


1.5.0.8 ships
'''Then when 1.5.0.8 ships, AUS should advertise...'''
1.0 - 1.5.0.7 -> 1.5.0.8 (minor)
1.0 - 1.5.0.7 -> 1.5.0.8 (minor)
1.5.0.8 -> 2.0.0.0 (major)
1.5.0.8 -> 2.0.0.0 (major)
2.0.0.0 -> no update
2.0.0.0 -> no update


2.0.0.1 ships
'''Then when 2.0.0.1 ships, AUS should advertise...'''
1.0 - 1.5.0.7 -> 1.5.0.8 (minor)
1.0 - 1.5.0.7 -> 1.5.0.8 (minor)
1.5.0.8 -> 2.0.0.1 (major)
1.5.0.8 -> 2.0.0.1 (major)
2.0.0.0 -> 2.0.0.1 (minor)
2.0.0.0 -> 2.0.0.1 (minor)
2.0.0.1 -> no update
2.0.0.1 -> no update


1.5.0.9 ships
'''Then when 1.5.0.9 ships, AUS should advertise...'''
1.0 - 1.5.0.8 -> 1.5.0.9 (minor)
1.0 - 1.5.0.8 -> 1.5.0.9 (minor)
1.5.0.9 -> 2.0.0.1 (major)
1.5.0.9 -> 2.0.0.1 (major)
2.0.0.0 -> 2.0.0.1 (minor)
2.0.0.0 -> 2.0.0.1 (minor)
2.0.0.1 -> no update
2.0.0.1 -> no update


3.0.0.0 ships
'''Then when 3.0.0.0 ships, AUS should advertise...'''
1.0 - 1.5.0.8 -> 1.5.0.9 (minor)
1.0 - 1.5.0.8 -> 1.5.0.9 (minor)
1.5.0.9 -> 2.0.0.1 (major, if platform is not supported)
1.5.0.9 -> 2.0.0.1 (major, if platform is not supported)
1.5.0.9 -> 3.0.0.0 (major, if platform is supported)
1.5.0.9 -> 3.0.0.0 (major, if platform is supported)
2.0.0.0 -> 2.0.0.1 (minor)
2.0.0.0 -> 2.0.0.1 (minor)
2.0.0.1 -> 3.0.0.0 (major, if platform is supported)
2.0.0.1 -> 3.0.0.0 (major, if platform is supported)  
2.0.0.1 -> no update (if platform is not supported)
2.0.0.1 -> no update (if platform is not supported)
3.0.0.0 -> no update
3.0.0.0 -> no update


3.0.0.1 ships
'''Then when 3.0.0.1 ships, AUS should advertise...'''
1.0 - 1.5.0.8 -> 1.5.0.9 (minor)
1.0 - 1.5.0.8 -> 1.5.0.9 (minor)
1.5.0.9 -> 3.0.0.1 (major, if platform is supported)
1.5.0.9 -> 3.0.0.1 (major, if platform is supported)
1.5.0.9 -> 2.0.0.1 (major, if platform is not supported)
1.5.0.9 -> 2.0.0.1 (major, if platform is not supported)
2.0.0.0 -> 2.0.0.1 (minor)
2.0.0.0 -> 2.0.0.1 (minor)
2.0.0.1 -> 3.0.0.1 (major, if platform is supported)
2.0.0.1 -> 3.0.0.1 (major, if platform is supported)
2.0.0.1 -> no update (if platform is not supported)
2.0.0.1 -> no update (if platform is not supported)
3.0.0.0 -> 3.0.0.1 (minor)
3.0.0.0 -> 3.0.0.1 (minor)
3.0.0.1 -> no update
3.0.0.1 -> no update


2.0.0.2 ships
'''Then when 2.0.0.2 ships, AUS should advertise...'''
1.0 - 1.5.0.8 -> 1.5.0.9 (minor)
1.0 - 1.5.0.8 -> 1.5.0.9 (minor)
1.5.0.9 -> 3.0.0.1 (major, if platform is supported)
1.5.0.9 -> 3.0.0.1 (major, if platform is supported)
1.5.0.9 -> 2.0.0.2 (major, if platform is not supported)
1.5.0.9 -> 2.0.0.2 (major, if platform is not supported)
2.0.0.0 - 2.0.0.1 -> 2.0.0.2 (minor)
2.0.0.0 - 2.0.0.1 -> 2.0.0.2 (minor)
2.0.0.2 -> 3.0.0.1 (major, if platform is supported)
2.0.0.2 -> 3.0.0.1 (major, if platform is supported)
2.0.0.2 -> no update (if platform is not supported)
2.0.0.2 -> no update (if platform is not supported)
3.0.0.0 -> 3.0.0.1 (minor)
3.0.0.0 -> 3.0.0.1 (minor)
3.0.0.1 -> no update
3.0.0.1 -> no update


1.5.0.10 ships
'''Then when 1.5.0.10 ships, AUS should advertise...'''
1.0 - 1.5.0.9 -> 1.5.0.10 (minor)
1.0 - 1.5.0.9 -> 1.5.0.10 (minor)
1.5.0.10 -> 3.0.0.1 (major, if platform is supported)
1.5.0.10 -> 3.0.0.1 (major, if platform is supported)
1.5.0.10 -> 2.0.0.2 (major, if platform is not supported)
1.5.0.10 -> 2.0.0.2 (major, if platform is not supported)
2.0.0.0 - 2.0.0.1 -> 2.0.0.2 (minor)
2.0.0.0 - 2.0.0.1 -> 2.0.0.2 (minor)
2.0.0.2 -> 3.0.0.1 (major, if platform is supported)
2.0.0.2 -> 3.0.0.1 (major, if platform is supported)
2.0.0.2 -> no update (if platform is not supported)
2.0.0.2 -> no update (if platform is not supported)
3.0.0.0 -> 3.0.0.1 (minor)
3.0.0.0 -> 3.0.0.1 (minor)
3.0.0.1 -> no update
3.0.0.1 -> no update

Latest revision as of 10:01, 13 January 2007

Major Update Use Cases

Let's assume that in each of these cases a Major Update is also available (2.0.0.0):

a) -1 from current minor version (i.e. I have 1.5.0.7 and 1.5.0.8 is published) 

Result: User should get the minor update.  No offer of Major will be made

b) -x from current minor version (i.e. I have 1.5.0.3 and 1.5.0.8 is published) 

Result: User should get the minor update.  No offer of Major will be made

c) at current minor version (I have 1.5.0.8 and the only newer version is 2.0.0.0) 

Result: User should get the offer for major upgrade to 2.0.0.0

d) at current minor version (I have 1.5.0.8 and the only newer version is 2.0.0.0) and have clicked "never" to previous major update offer 

Result: User should get no update.

e) at current minor version (I have 1.5.0.8 and the only newer version is 2.0.0.0) and have clicked "never" to previous major update offer - however we've offered a new major version (i.e. 2.1) 

Result: User should get major update offer to 2.1

Summary

The only time I get a major offer is if: 

a) There is no minor update for me (I'm at the latest point release)
AND
b) I've not clicked never for this major update version 
   OR 
   I've done a manual "Check for Updates..."

If you do a manual check for updates, we'll clear the per version "never" client side pref for the major update you are presented. This allows the user to "undo" the never decision.

Notes

  • A never decision does not affect minor updates, only major updates. (See https://bugzilla.mozilla.org/show_bug.cgi?id=350636 for why this matters.)
  • If the server side accidentally offered a major update to Fx 1.5.0.7 (and below), it would be bad because the user would get the major update without having agreed to the EULA. There is nothing in 1.5.0.7 (and below) on the client side to prevent this, so we need a safeguard on the server side.
  • At some point (Firefox 3, according to bug https://bugzilla.mozilla.org/show_bug.cgi?id=341190), we plan to stop supporting Windows 98/ME. Unlike Fx 1.5.x, Fx 2.0+ sends the OS version as part of the update url when it pings the AUS server. Again, this is something the server side will take care of, by not presenting incompatible major updates to clients running on unsupported OSes. See https://bugzilla.mozilla.org/show_bug.cgi?id=341190 for details

Example Table

Starting point, 1.5.0.7 has shipped.

When 2.0.0.0 ships, AUS should advertise... 

1.0 - 1.5.0.6 -> 1.5.0.7 (minor)
1.5.0.7 -> no update (since only 1.5.0.8+ can handle a major update)
2.0.0.0 -> no update

Then when 1.5.0.8 ships, AUS should advertise... 

1.0 - 1.5.0.7 -> 1.5.0.8 (minor)
1.5.0.8 -> 2.0.0.0 (major)
2.0.0.0 -> no update

Then when 2.0.0.1 ships, AUS should advertise... 

1.0 - 1.5.0.7 -> 1.5.0.8 (minor)
1.5.0.8 -> 2.0.0.1 (major)
2.0.0.0 -> 2.0.0.1 (minor)
2.0.0.1 -> no update

Then when 1.5.0.9 ships, AUS should advertise... 

1.0 - 1.5.0.8 -> 1.5.0.9 (minor)
1.5.0.9 -> 2.0.0.1 (major)
2.0.0.0 -> 2.0.0.1 (minor)
2.0.0.1 -> no update

Then when 3.0.0.0 ships, AUS should advertise... 

1.0 - 1.5.0.8 -> 1.5.0.9 (minor)
1.5.0.9 -> 2.0.0.1 (major, if platform is not supported)
1.5.0.9 -> 3.0.0.0 (major, if platform is supported)
2.0.0.0 -> 2.0.0.1 (minor)
2.0.0.1 -> 3.0.0.0 (major, if platform is supported) 
2.0.0.1 -> no update (if platform is not supported)
3.0.0.0 -> no update

Then when 3.0.0.1 ships, AUS should advertise... 

1.0 - 1.5.0.8 -> 1.5.0.9 (minor)
1.5.0.9 -> 3.0.0.1 (major, if platform is supported)
1.5.0.9 -> 2.0.0.1 (major, if platform is not supported)
2.0.0.0 -> 2.0.0.1 (minor)
2.0.0.1 -> 3.0.0.1 (major, if platform is supported)
2.0.0.1 -> no update (if platform is not supported)
3.0.0.0 -> 3.0.0.1 (minor)
3.0.0.1 -> no update

Then when 2.0.0.2 ships, AUS should advertise... 

1.0 - 1.5.0.8 -> 1.5.0.9 (minor)
1.5.0.9 -> 3.0.0.1 (major, if platform is supported)
1.5.0.9 -> 2.0.0.2 (major, if platform is not supported)
2.0.0.0 - 2.0.0.1 -> 2.0.0.2 (minor)
2.0.0.2 -> 3.0.0.1 (major, if platform is supported)
2.0.0.2 -> no update (if platform is not supported)
3.0.0.0 -> 3.0.0.1 (minor)
3.0.0.1 -> no update

Then when 1.5.0.10 ships, AUS should advertise... 

1.0 - 1.5.0.9 -> 1.5.0.10 (minor)
1.5.0.10 -> 3.0.0.1 (major, if platform is supported)
1.5.0.10 -> 2.0.0.2 (major, if platform is not supported)
2.0.0.0 - 2.0.0.1 -> 2.0.0.2 (minor)
2.0.0.2 -> 3.0.0.1 (major, if platform is supported)
2.0.0.2 -> no update (if platform is not supported)
3.0.0.0 -> 3.0.0.1 (minor)
3.0.0.1 -> no update
Retrieved from "https://wiki.allizom.org/index.php?title=Software_Update:Major_Update_Use_Cases&oldid=46307"