This highlights that the FileHandler class can also be seen as a method
similar to open, and it removes unnecessary context managers, allowing
plugins to close files as they wish (they must, however, remember to
close the file for it to be committed).
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.
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