[wp-hackers] Plugin Management and Autoupdate System

[Computer Guru]

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

That's not bad:
"This plugin hasn't been verified working on this version of WP. Do you want
to continue?"

But, the problem is when you _upgrade_ to a new version of WP, and find your
old plugins suddenly disabled - that's what I don't like.

WP has come a _long_ way since the 1.5 days, we're reaching out more, and
plugin devs are more aware of changes and less 'lazy.'
I don't see the need to fix something that isn't broken. Let plugin authors
verify a plugin is broke.

Now, there -is- another option, but I don't like it: a central server. But
the whole goal of RDF over XML-RC was to avoid centralized nonsense and
delays. I'd rather we just took our chances with only marking verified broke
plugins as such, and left it otherwise untouched. This solution is far more
elegant, much cheaper, and not dependant on one server - remember what
happened when wp-plugins.org went down?


Computer Guru
NeoSmart Technologies
http://neosmart.net/blog/


> -----Original Message-----
> From: wp-hackers-bounces at lists.automattic.com [mailto:wp-hackers-
> bounces at lists.automattic.com] On Behalf Of jason switzer
> Sent: Sunday, July 30, 2006 5:50 PM
> To: wp-hackers at lists.automattic.com
> Subject: Re: [wp-hackers] Plugin Management and Autoupdate System
> 
> 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.
> >
> 
> 
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers