So this allows people to alter the APIs for their plugins and allows
plugins to verify the API is compatible with the one they expect.
It adds a version property to Plugin classes, and has a SemVer checking
method which can be called from other plugins to verify a plugin against
a particular version.
So this feels like a contentious decision. It'd be awesome to have the
options for the methods stored along-side the methods themselves.
The downside with this is that the thing accessing the configuration
data is always the plugin, so it's the plugin that must have requested
the configuration option. This is also important in case the
description of the configuration option needs modifying for clarity or
providing context for how it will be used.
If the interface changes, all plugins calling the plugin methods will
need updating, so the config options can be updated if necessary.
Context.object accepts a template or a string name (and now a type
flag). Module.object only accepts a string (because a template already
has most of the stuff built in and might as well be passed to the
Context.object constructor).
The gotcha here is the absolute flag, which must now be set
appropriately in all cases *except* where the module is constructed
with an offset of 0 (whereby it will have no impact).
This should have no impact functionality-wise.
The statistics plugin was left out a) as an example and b) because it
was committed by mistake in the first place and was never meant to be a
real plugin.
Mike Auty