[wp-hackers] Simplicity in 2.next

[Jon Abad]

 From the Mozilla Extension Versioning page:
http://www.mozilla.org/projects/firefox/extensions/update.html

    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 
necessary.

jon


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.
>
> Andy
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
>