|
|
| Line 40: |
Line 40: |
| =The Updates File= | | =The Updates File= |
|
| |
|
| update.xml is an XML file that tells about available updates. It is formatted
| | See http://wiki.mozilla.org/Software_Update:updates.xml_Format for documentation of this format. |
| like this:
| |
| | |
| <tt><pre>
| |
| <?xml version="1.0"?>
| |
| | |
| <updates>
| |
| <update type="minor" version="1.0.4" extensionversion="1.0"
| |
| detailsURL="http://www.foo.com/1.0.4/whatsnew.html">
| |
| <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" extensionversion="1.1"
| |
| detailsURL="http://www.foo.com/1.1.2/whatsnew.html">
| |
| <patch type="complete" url="http://www.foo.com/1.1.2-complete.xpi"
| |
| hashfunction="" hashvalue="" size=""/>
| |
| </update>
| |
| </updates>
| |
| </pre></tt>
| |
| | |
| The application should provide a preference setting that can be set to hold
| |
| 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
| |
| installed and may play a role in updating the application.
| |
| | |
| Each "partial" update is a diff of the new version from the previous version.
| |
| 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
| |
| 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
| |
| 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
| |
| is reached at which we can no longer fully update a user to the newest version,
| |
| we can provide a series of updates that take them to a version that can then
| |
| be updated further, e.g.
| |
| | |
| User is using 1.1.1
| |
| 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:
| |
| | |
| <tt><pre>
| |
| <?xml version="1.0"?>
| |
| | |
| <updates>
| |
| <update type="minor" version="1.1.2" extensionversion="1.1"
| |
| detailsURL="http://www.foo.com/1.1.2/whatsnew.html">
| |
| <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" extensionversion="1.1"
| |
| detailsURL="http://www.foo.com/1.1.3/whatsnew.html">
| |
| <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" extensionversion="1.1"
| |
| detailsURL="http://www.foo.com/1.1.4/whatsnew.html">
| |
| <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>
| |
| | |
| </pre></tt>
| |
| | |
| And for the 1.1.4 user like so:
| |
| | |
| <tt><pre>
| |
| <?xml version="1.0"?>
| |
| | |
| <updates>
| |
| <update type="minor" version="1.1.5" extensionversion="1.1"
| |
| detailsURL="http://www.foo.com/1.1.5/whatsnew.html">
| |
| <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" extensionversion="1.5"
| |
| detailsURL="http://www.foo.com/1.5.9/whatsnew.html">
| |
| <patch type="complete" url="http://www.foo.com/1.5.9-complete.xpi"
| |
| hashfunction="" hashvalue="" size=""/>
| |
| </update>
| |
| </updates>
| |
| | |
| </pre></tt>
| |
| | |
| 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).
| |
| | |
| | |
| On the client side:
| |
| We can have a [Update Details] button under menu: [Help] > [About Mozilla Firefox].
| |
| By clicking this button [Update Details] we can present a tabluar view with the following columns:
| |
| 1. Updated Item
| |
| 2. Version
| |
| 3. Type { Security update or enhancement update...}
| |
| 4. Updated Item release date
| |
| 5. Updated date
| |
| 6. Updated by user ?
| |
|
| |
|
| = Preference Controls and State = | | = Preference Controls and State = |