Software Update:Checking For Updates: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
 
 
(30 intermediate revisions by 5 users not shown)
Line 1: Line 1:
Update Service
Back to [[Software Update]]


- checks for updates to the application on a background timer
The Update Service:
- provides a means for the user to check for updates to the application
- provide a set of controls for determining update behavior


The Update Check
* checks for updates to the application on a background timer
* provides a means for the user to check for updates to the application
* provide a set of controls for determining update behavior


1. generate update service URL
= The Background Timer =
2. determine if updates are available
3. determine action
4. download patches
5. verify patches
6. install patches


The Update Service URL
The system will automatically check for updates without user intervention:
* every 24 hours
* on the first startup following an update, to check to see if the patch applied is the newest possible update or if there are newer ones.


- needs to incorporate data in these dimensions:
  - app name
  - app locale
  - app version
  - app buildid (for distinguishing between nightlies on a
    "tester" build stream for example)
  - app buildtarget


e.g.  
Regarding critical security updates, it would be useful to the user, if we could display a pop-up or similar sort (like what we have for-- " New updates available ") with the importance of this critical security update. This way we can inform the user the urgent need for the upgrade.


  /firefox/1.0.3.20050414/i586-pc-msvc/en-US/update.xml
= The Update Check =


The Updates File
# generate update service URL
# determine if updates are available
# determine action
# download patches
# verify patches
# install patches


update.xml is an XML file that tells about available updates. It is formatted
= Update Service URL =
like this:


<?xml version="1.0"?>
The Service URL needs to incorporate data in these dimensions so as to reduce the complexity of the processing on the client side:
* service URL schema version (so we can change it in the future)
* app name
* app version
* app buildid (for distinguishing between nightlies on a "tester" build stream for example)
* app buildtarget
* app locale
* aus channel
* distribution name
* distribution version


<updates>
e.g.,
  <update type="minor" version="1.0.4">
    <patch type="partial" url="http://www.foo.com/1.0.4-partial.xpi"
          hashfunction="" hashvalue="" size=""/>
    <patch type="complete" url="http://www.foo.com/1.0.4-complete.xpi"
          hashfunction="" hashvalue="" size=""/>
  </update>
  ..
  <update type="major" version="1.1.2">
    <patch type="complete" url="http://www.foo.com/1.1.2-complete.xpi"
          hashfunction="" hashvalue="" size=""/>
  </update>
</updates>


The application should provide a preference setting that can be set to hold
<tt>/update/3/Firefox/3.0a8pre/2007083015/Darwin_x86-gcc3/en-US/default/Darwin%208.10.1/testpartner/1.0/update.xml</tt>
the application within one version range, e.g. within 1.0.x, never updating
to the newest major version but only installing incremental security updates.


The <updates> list specifies the set of updates that can be downloaded and
See app.update.url below for the template used in creating the Service URL.
installed and may play a role in updating the application.


Each "partial" update is a diff of the new version from the previous version.
=The Updates File=
If there are several "partial" updates available, they are all downloaded and
installed in order. [Note: Initially we may only install a single patch and
then rely on a subsequent update check to determine that there are more patches
available and install them at that time.]


Before a collection of updates is downloaded and installed, the size attribute
See [[Software_Update:updates.xml_Format]] for documentation of this format.
for each patch is read to determine file size, and if the sum of the patch
sizes is found to be greater than the size of the "complete" patch (which is
a jar file whose contents are only file additions, removals and replaces, no
file patches), then the "complete" file is downloaded.  


We only supply "complete" updates to major versions since we cannot easily pick
= Preference Controls and State =
a version to diff against off of a previous version series, e.g. do we diff
off 1.1.4? What if we do a security release 1.1.5 further down the line? It
is simpler to make users doing major upgrades redownload the bundle.


This system intrinsically supports updates to the updater - if a point in time
* <tt>app.update.enabled</tt>
is reached at which we can no longer fully update a user to the newest version,
  <blockquote>
we can provide a series of updates that take them to a version that can then
    <table border="1" cellspacing="0" cellpadding="3">
be updated further, e.g.
      <tr><td><tt>'''true'''</tt></td><td>Enables background update checking</td></tr>
      <tr><td><tt>'''false'''</tt></td><td>Disables background update checking</td></tr>
    </table>
  </blockquote>
* <tt>app.update.mode</tt>
  <blockquote>
    <table border="1" cellspacing="0" cellpadding="3">
      <tr><td>'''0'''</td>
          <td>automatically download updates for minor and major updates, regardless of incompatibilities that may arise with addons</td></tr>
      <tr><td>'''1'''</td>
          <td>automatically download updates for minor and major releases, if no incompatibilities with addons are present, otherwise prompt</td></tr>
      <tr><td>'''2'''</td>
          <td>automatically download updates for minor releases, prompt about major releases</td></tr>
      <tr><td>'''3'''</td>
          <td>prompt about minor and major releases</td></tr>
    </table>
  </blockquote>
* <tt>app.update.interval</tt>
  <blockquote>
    <table border="1" cellspacing="0" cellpadding="3">
      <tr><td>'''86400'''</td><td>seconds between update checks</td></tr>
    </table>
  </blockquote>
* <tt>app.update.timer</tt>
  <blockquote>
    <table border="1" cellspacing="0" cellpadding="3">
      <tr><td>'''5000'''</td><td>milliseconds between app.update.interval expiry checks</td></tr>
    </table>
  </blockquote>
* <tt>app.update.silent</tt>
  <blockquote>
    <table border="1" cellspacing="0" cellpadding="3">
      <tr><td>'''true'''</td><td>all update prompting should be suppressed</td></tr>
      <tr><td>'''false'''</td><td>show prompts to the user when there are events they should respond to</td></tr>
    </table>
  </blockquote>
* <tt>app.update.lastUpdateDate.background-update-timer</tt>
  <blockquote>
    <table border="1" cellspacing="0" cellpadding="3">
      <tr><td>'''1114648397'''</td><td>seconds since epoch of last update time</td></tr>
    </table>
  </blockquote>
* <tt>app.update.url</tt>
  <blockquote>
    <table border="1" cellspacing="0" cellpadding="3">
      <tr><td>'''https://aus2.mozilla.org/update/3/%PRODUCT%/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/update.xml'''</td></tr>
      <tr><td>'3' is the schema version<br/>
PRODUCT: App name (e.g., 'Firefox')<br/>
VERSION: App version (e.g. '3.0a8pre')<br/>
BUILD_ID: Build ID (e.g., '2007083015')<br/>
BUILD_TARGET: Build target (e.g., 'Darwin_x86-gcc3')<br/>
LOCALE: App locale (e.g., 'en-US')<br/>
CHANNEL: AUS channel (e.g., 'default')<br/>
OS_VERSION: Operating System version (e.g., 'Darwin%208.10.1')<br/>
DISTRIBUTION: Name of customized distribution, if any (e.g., 'testpartner')<br/>
DISTRIBUTION_VERSION: Version of the customized distribution (e.g., '1.0)
</td></tr>
    </table>
  </blockquote>


User is using 1.1.1
Back to [[Software Update]]
Newest version is 1.5.9 but due to a bug in the updater in all versions older
than 1.1.4, the user cannot update directly to 1.5.9.
 
The update.xml file for the 1.1.1 user might look something like this:
 
<?xml version="1.0"?>
 
<updates>
  <update type="minor" version="1.1.2">
    <patch type="partial" url="http://www.foo.com/1.1.2-partial.xpi"
          hashfunction="" hashvalue="" size=""/>
    <patch type="complete" url="http://www.foo.com/1.1.2-complete.xpi"
          hashfunction="" hashvalue="" size=""/>
  </update>
  <update type="minor" version="1.1.3">
    <patch type="partial" url="http://www.foo.com/1.1.3-partial.xpi"
          hashfunction="" hashvalue="" size=""/>
    <patch type="complete" url="http://www.foo.com/1.1.3-complete.xpi"
          hashfunction="" hashvalue="" size=""/>
  </update>
  <update type="minor" version="1.1.4">
    <patch type="partial" url="http://www.foo.com/1.1.4-partial.xpi"
          hashfunction="" hashvalue="" size=""/>
    <patch type="complete" url="http://www.foo.com/1.1.4-complete.xpi"
          hashfunction="" hashvalue="" size=""/>
  </update>
</updates>
 
And for the 1.1.4 user like so:
 
<?xml version="1.0"?>
 
<updates>
  <update type="minor" version="1.1.5">
    <patch type="partial" url="http://www.foo.com/1.1.5-partial.xpi"
          hashfunction="" hashvalue="" size=""/>
    <patch type="complete" url="http://www.foo.com/1.1.5-complete.xpi"
          hashfunction="" hashvalue="" size=""/>
  </update>
  <update type="major" version="1.5.9">
    <patch type="complete" url="http://www.foo.com/1.5.9-complete.xpi"
          hashfunction="" hashvalue="" size=""/>
  </update>
</updates>
 
So the user of 1.1.1 will have the 1.1.2, 1.1.3, and 1.1.4 patches
downloaded and applied in that order. When they start the application the next
time, the application will recheck for updates using 1.1.4's enhanced bugfixed
updater, and discover 1.1.5 and the 1.5.9 major update.
 
This implies that the database that manages all of this version information
has to know that some updates can only apply to certain version (ranges).
 
Extensions
* eventually move EM updating fully into EM

Latest revision as of 01:30, 2 October 2007

Back to Software Update

The Update Service:

  • checks for updates to the application on a background timer
  • provides a means for the user to check for updates to the application
  • provide a set of controls for determining update behavior

The Background Timer

The system will automatically check for updates without user intervention:

  • every 24 hours
  • on the first startup following an update, to check to see if the patch applied is the newest possible update or if there are newer ones.


Regarding critical security updates, it would be useful to the user, if we could display a pop-up or similar sort (like what we have for-- " New updates available ") with the importance of this critical security update. This way we can inform the user the urgent need for the upgrade.

The Update Check

  1. generate update service URL
  2. determine if updates are available
  3. determine action
  4. download patches
  5. verify patches
  6. install patches

Update Service URL

The Service URL needs to incorporate data in these dimensions so as to reduce the complexity of the processing on the client side:

  • service URL schema version (so we can change it in the future)
  • app name
  • app version
  • app buildid (for distinguishing between nightlies on a "tester" build stream for example)
  • app buildtarget
  • app locale
  • aus channel
  • distribution name
  • distribution version

e.g.,

/update/3/Firefox/3.0a8pre/2007083015/Darwin_x86-gcc3/en-US/default/Darwin%208.10.1/testpartner/1.0/update.xml

See app.update.url below for the template used in creating the Service URL.

The Updates File

See Software_Update:updates.xml_Format for documentation of this format.

Preference Controls and State

  • app.update.enabled
trueEnables background update checking
falseDisables background update checking
  • app.update.mode
0 automatically download updates for minor and major updates, regardless of incompatibilities that may arise with addons
1 automatically download updates for minor and major releases, if no incompatibilities with addons are present, otherwise prompt
2 automatically download updates for minor releases, prompt about major releases
3 prompt about minor and major releases
  • app.update.interval
86400seconds between update checks
  • app.update.timer
5000milliseconds between app.update.interval expiry checks
  • app.update.silent
trueall update prompting should be suppressed
falseshow prompts to the user when there are events they should respond to
  • app.update.lastUpdateDate.background-update-timer
1114648397seconds since epoch of last update time
  • app.update.url
https://aus2.mozilla.org/update/3/%PRODUCT%/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/update.xml
'3' is the schema version

PRODUCT: App name (e.g., 'Firefox')
VERSION: App version (e.g. '3.0a8pre')
BUILD_ID: Build ID (e.g., '2007083015')
BUILD_TARGET: Build target (e.g., 'Darwin_x86-gcc3')
LOCALE: App locale (e.g., 'en-US')
CHANNEL: AUS channel (e.g., 'default')
OS_VERSION: Operating System version (e.g., 'Darwin%208.10.1')
DISTRIBUTION: Name of customized distribution, if any (e.g., 'testpartner')
DISTRIBUTION_VERSION: Version of the customized distribution (e.g., '1.0)

Back to Software Update

Retrieved from "https://wiki.allizom.org/index.php?title=Software_Update:Checking_For_Updates&oldid=69958"