=The Updates File=
update.xml is an XML file that tells about available updates. It is formattedlike 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 holdthe application within one version range, e.g. within 1.0.x, never updatingto the newest major version but only installing incremental security updates. The <updates> list specifies the set of updates that can be downloaded andinstalled 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 andinstalled in order. [Note: Initially we may only install a single patch andthen rely on a subsequent update check to determine that there are more patchesavailable and install them at that time.] Before a collection of updates is downloaded and installed, the size attributefor 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 picka version to diff against off of a previous version series, e.g. do we diffoff 1.1.4? What if we do a security release 1.1.5 further down the line? Itis simpler to make users doing major upgrades redownload the bundle. This system intrinsically supports updates to the updater - if a point in timeis 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 thenbe updated further, e.g. User is using 1.1.1Newest 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="See http://www.foo.com/1wiki.1mozilla.5-partial.xpi" hashfunction="" hashvalue="" size=""org/> <patch type="complete" url="httpSoftware_Update://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 patchesdownloaded and applied in that order. When they start the application the nexttime, the application will recheck xml_Format for updates using 1.1.4's enhanced bugfixedupdater, and discover 1.1.5 and the 1.5.9 major update. This implies that the database that manages all documentation of this version informationhas 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 6format. Updated by user ?
= Preference Controls and State =
