r3624 includes code that requires that your plugins include their info
in an XML file AND that the plugin itself does not contain a method
named info().

Since all plugins were previously required to have a method named
info(), all plugins that worked in previous revisions will now break
your site.

The easiest way to update a plugin right now is to create a file with
the same name, but an xml extension instead of php, and put content like
this inside it:

<?xml version="1.0" encoding="utf-8" ?>
<pluggable type="plugin">
<name>Test Plugin</name>
<license url="http://www.apache.org/licenses/LICENSE-2.0.html">Apache
Software License 2.0</license>
<author url="http://habariproject.org/">Habari Community</author>
<version>1.0</version>
<url>http://habariproject.org/</url>
<description><![CDATA[This is a test plugin.]]></description>
<copyright>2009</copyright>
</pluggable>

Note three things about this XML:

1. The base element is <pluggable>, not <plugin>.
2. It's easiest to make sure everything works properly right now if it
has the same elements as what you see here in the same order.
3. This format should be used for theme too, but with a different type
attribute.

That all may change, but it's what should currently be working within
this commit.

You'll need that file and to remove the info() method from the plugin.

We'd do good to soon post a transition guide that provides instructions
for transitioning existing plugins to the 0.7 info schema, including how
to branch the plugin source to separate it from any working 0.6 plugin
version.  Anyone?

I also forgot to mention that plugin dependencies are starting to work
in code.  If a plugin requires some feature and it is not present, then
it will list the dependency and will not let you activate it.

I an hoping that we can get a dependency reference online somewhere to
indicate what any specific feature requires in implementation.  So if a
plugin or theme specifies "tag_cloud" as a dependency, you'd go to a
page on hp.o to see which plugins supported that feature, and what they
had to do to provide that support.

So rather than a theme saying "I work with plugins X, Y, and Z", the
theme can say "I work with feature A", and any plugin that implements
feature A will provide the necessary functionality to enable those
features.  I imagine that "areas" will be a feature that themes commonly
provide, and plugins that provide blocks will often require the "areas"
feature for activation.

Owen