How about a feature in the admin menu that lists the active plugins and their versions?
I also propose a header for plugins, like Wordpress has, where meta information can be stored.
And since I don’t see a good reason to divert from an already existing de-facto standard, I propose the following lines to be prepended to plugin.rb:
# Plugin Name: Name Of The Plugin
# Plugin URI: http://URI_Of_Page_Describing_Plugin_and_Updates
# Description: A brief description of the Plugin.
# Version: The Plugin's Version Number, e.g.: 1.0
# Author: Name Of The Plugin Author
# Author URI: http://URI_Of_The_Plugin_Author
# License: A "Slug" license name e.g. GPL2
Alternatively, a file called
pluginmeta.yml could be stored next to
EDIT: I do see a reason to extend an existing standard. Let’s introduce a
Minimum Discourse Version field as well, which indicates the minimum Discourse version the plugin requires.
I’d love it if SemVer was strongly recommended or even required.
Author URL should be optional.
Recommended additions, both mandatory:
# Compatibility: Last version of Discourse tested against.
# Contact: How can the developer(s) be reached?
I don’t know how exactly WordPress does its compatibility check that prompts the “this plugin has not been tested with your version”-notice when you install/update a plugin from within the admin panel, but I think it’s an incredibly useful heads-up and I figured this would be a decent first take on it.
(I think it’s based on the “Broken/Works” user vote data they gather after the plugin has been submitted. Still don’t know where they get the “Required: some version” and “Compatible up to: some version” though.)
As for contact, it’s just my belief that any self-respecting open source developer ought have an open line of communication of some sort. It wouldn’t have to be an e-mail, but there should be something put there that indicates how the developer would prefer to be contacted.
Totally agree about SemVer, I’m hoping that Discourse will be using that as well as soon as 1.0 is reached.
I like your additions as well.
Looks like sam already came up with a format for meta information that he used in this example. Perhaps build on that?
That’s basically what I did, just replacing descriptions that were IMO a bit too vague, since it are general properties, such as ‘name’, with ‘plugin name’