[wp-hackers] Plugin Management and Autoupdate System

[jason switzer]

On 7/30/06, Computer Guru <computerguru at neosmart.net> wrote:
>
> > WP 2.1 is going to break plugins with some of its database changes.
> > Incomplete API leads to deep-reaching plugins which will break when
> > things change.  But this isn't something that a plugin author is likely
> > to know ahead of time, so I agree that a max version header in a plugin
> > is of little use.  I HATE how Firefox disables things, and wouldn't
> > want that kind of behavior in WordPress.  However, such a check could
> > be done on server side.  That is, when a new WP version comes out and
> > an old plugin is found to be broken, it could be flagged appropriately
> > on the update server, and the plugin could be disabled, or a notice put
> > up (assuming that its brokenness doesn't kill the wp-admin, as is
> > sometimes the case).
>
> I run the 2.1 SVN at all times. I have a _lot_ of plugins. Most changes
> required but a db-query variable change and they were up and running again
> -
> that easy.
>
> I agree with your POV 100% - It should be flagged as incompatible only
> when
> the dev deems it to be so. My way of tackling this problem is by keeping
> the
> maxversion field, but in the API docs making it clear that this field
> should
> ONLY be used _if and only when_ the plugin is verified broken.
>
> The RDF generator will not have a "Max WP version" field, but rather a
> "This
> plugin breaks if used on a WP version above:" field - to discourage the
> overzealous.
>


I would think that at the very least, the plugin could be marked unstable
similar to many linux distributions. The end user could then choose to
install unstable packages at their own risk.