Architectural thoughts on the addon mechanism — API versioning, lifecycle states, manager behaviour

The addon status was discussed when I implemented the Addon Manager. It is intended to indicate the lifecycle state of an addon, and will typically progress forwards form Unstable to Stable. It is roughly equivalent to the addon rating in our wiki and took inspiration from the mediawiki extension status.

Unstable = In the early stages of development.
Experimental = Usable, but expect many bugs.
Beta = Ready for wider testing.
Stable = Complete.

I considered adding “Unmaintained”, but concluded that the new maintainer fields were sufficient. We can review this though.

The include_in_listing field indicates the published/unpublished state of the addon.

I can’t remember discussing the end-of-life of an addon before. We rarely remove addons, but when we do we just delete them. Anyone interested in finding them would have to look in the git repository.

Gramps core doesn’t use semantic versioning, but does use something similar with our major, feature and maintenance releases. I’m not sure that a separate API version would gain us much since it would likely increment for every feature release.

We already have this functionality, but I didn’t enhance it when I created the Addon Manager.

We also need to think about how we handle running more than one version of Gramps. Especially the case where an addon changes between versions. Are we going to keep the versioned directory structure?