[wp-hackers] Development Process

[Doug Stewart]

This might be slightly orthogonal to the current discussion, but I think
the overall flow of the conversation points to a huge, HUGE feature that
WordPress and WP users alike would benefit greatly from: a unified,
OFFICIAL plugin update mechanism.

Plugins have increasingly become one of the huge reasons for the
widespread use of WP - they add manifold functionality for everything
from wikifying a blog to making image galleries to podcasting to turning
WP into a full-featured CMS.  Plugins also, carelessly-written, open WP
up to many security holes.  Like it or not, these security issues end up
being blamed on the WP core.

There needs to be a Dashboard widget that alerts blog owners to the fact
that DrDave has updated SK2, that Mark J.'s Subscribe To plugin has
patched a security hole, or that Skippy's Gravatars plugin now lets you
select between curl() and fopen().

The more I think about it, the better of an idea this seems to me. 
Plugin informational payloads should include a field for revision number
(with a WP core-enforced numbering scheme so we avoid idiocy like the
Epoch issues that plagued the early goings of Fedora Core), a brief
description of the changes and a change/issues fixed flag - does the
patch address security issues, is it a simple bugfix, or is it a feature
enhancement release?  Slap an official color code scheme on that final
field (red for security, yellow for bugs, green for features, you get
the picture) and away you go.

Then, when these sorts of issues come up and are raised to the plugin
authors themselves, the burden lies upon them to publish a new rev and
update the plugin info repo with the appropriate details.

I know this issue has been discussed before, at-length, but I think it's
finally time to start addressing it in an official capacity.

YMMV, IANAWPD, etc.
--
------------
Doug Stewart
Systems Administrator/Web Applications Developer
Lockheed Martin Advanced Technology Labs
dstewart at atl.lmco.com