[wp-hackers] Simplicity in 2.next
jonabad at gmail.com
Mon Feb 6 23:58:28 GMT 2006
From the Mozilla Extension Versioning page:
Firefox uses the pref |app.extensions.version| to determine
Extension compatibility for this release. When an Extension is
installed, Firefox makes sure that |app.extensions.version| lies
within the range set up by the Extension's install.rdf file using
minVersion and maxVersion. If |app.extensions.version| is less than
minVersion, a newer version of Firefox is required to install the
Extension, if it is greater than maxVersion, Firefox is too new to
install the extension.
If this basic compatibility check fails, Firefox will then attempt
to "phone home" and obtain newer compatibility information for the
Extension. If the Extension's install.rdf file specifies an update
RDF file, this will be loaded and newer information discovered there
(see below for format). If none is supplied, Firefox will check the
generic update service running on addons.mozilla.org, and if the
Extension is hosted there and has newer compatibility information it
will be read and the local information updated.
If all of these methods fail, Firefox will show a message to the
user saying that the Extension is incompatible and cannot be installed.
The plugin has the max and min ver and then it looks for an update if
Andy Skelton wrote:
> On 2/6/06, Jon Abad <jonabad at gmail.com> wrote:
>> At minimum, this sounds like it would be useful to us: add a
>> WP-Version-Range line to the Plugin file structure so that people know
>> which versions the plugin has been tested on.
> To keep with the FF model, this should not be coded into the plugin
> but available via a URL to be checked as part of the upgrade process.
> Before the user copies all the new core files, one new file
> (pre-upgrade.php) is copied to ABSPATH and run from the browser. It
> goes through the installed/activated plugins one by one, checking the
> URL for compatibility notices and ending with a message stating which
> plugins are known-good, known-bad and untested. This way the user
> isn't already stuck with overwritten files and new db schema. It also
> provides a channel for explicit upgrade instructions, such as the
> ever-ignored advice to deactivate plugins, make backups, etc.
> The URL may be specified by the author in an additional line in the
> plugin's leading comments. Alternatively, plugins without the URL
> would be checked against a centralized list of tested plugins.
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
More information about the wp-hackers