Plugin Release/Submission Guidelines - updated requirements (Updated: March 15, 2012)

In order to ensure that server admins are able to easily find and keep up with plugins and their updates, we've opted to enforce a set of guidelines that every plugin release must adhere to in order to be in the Plugin Releases forum. While it means slightly more work for plugin developers and us, we feel that this is a worthy sacrifice to be made to make things easier for our community.

Required Information/Disallowed Content:
Plugin Release Title
To ensure that server admins can find out key information about a plugin from a glance and to make searching for plugins easier, we need to set specific requirements for plugin release thread titles.

The general format of your thread title should be:
[CATEGORY] PluginName v0.1 - Description [1.0.1-R1]

Where:
[CATEGORY] is (separated by / if in more than one, like [CAT1/CAT2]):

PluginName is the name of your plugin jar, without the .jar extension (this is so it is obvious to everyone what to search for when they're looking for updates for a plugin)
v0.1 is the latest version number for your plugin
Description is a brief description of your plugin's functionality
[1.0.1-R1.0] or [1.2.3-R0.2] is the CraftBukkit Recommended or Beta Build version this was tested against. This build title should be within the LAST THREE Recommended or Beta Builds of CraftBukkit UNLESS there are API breakages occurring between them or a Recommended or Beta Build has been promoted pertaining to a Minecraft update.

Changelog, other information:
Thought it may seem like overkill, we feel that requiring Plugin Developers to provide a changelog on their release post with a minimum amount of clicks (meaning not hidden in a spoiler) makes Server Admins' lives easier with very little extra effort on your part. To this end, we encourage and require that Plugin Developers provide a changelog at the end of the release post which contains the last two versions (if applicable), while providing the full changelog hidden in a spoiler. The specifics of this requirement is so that we can guarantee Server Admins will not have to keep expanding spoilers each time they need to check for a plugin update.

On top of a changelog, while not required, I suggest other important information like a Todo List and/or a Known Issues list be provided, as outlined in the tips section below.

Adf.ly, unfriendly download experience
We no longer allow the use of adf.ly links within Plugin Release threads due to them resulting in an extremely unpleasant download experience for our community. Though much of our community is fine with this, we've opted to ban the use of the service as new users having to deal with the unfriendly download experience is unacceptable.

As well as banning services like adf.ly, we also strongly recommend against using URL shorteners as there is no way for people to figure out where a URL shortener is going to without clicking, for the most part. We may or may not end up out-right banning the use of URL shorteners, however, for the time being, they are merely discouraged. For more information on these two decisions, please see this announcement.

---------------

Maintaining your release:
On top of actively supporting your plugin, providing updates and - hopefully - adding cool, new things we expect and require that Plugin Developers take a few minutes to test their plugins and update their thread titles with the latest Recommended Build # each time a new RB is promoted. It goes without saying that the specifics of this requirement adhere to what has previously been said about this.

Every so often staff will go around cleaning up the Plugin Releases forum and your plugin might get hit and marked as inactive or unsupported if you haven't updated your plugin, release post and your title within a reasonable amount of time.

If your plugin submission or release is found to not meet these guidelines, you can make the appropriate changes by editing your post or editing your thread title. Please be sure to read the FAQ in a further post before contacting staff with questions.

Any plugins not adhering to these guidelines (within reason) will be moved to Plugin Submissions until they've been updated to follow these Plugin Release guidelines.

-------------------

Tips and suggested template
Below are some tips on how to best present your plugins to users and get them wanting to use your plugins, as well as simplify and expedite the update process they need to go through to maintain their server by providing a uniform, easy to follow release post structure.

Plugin Release Content
Along with a properly formatted release thread title, taking some extra time and care to make your release presentable will increase the amount of users of your plugin and reduce the amount of support calls you'll have to make.

The first element in a proper release is to recommunicate the name of your plugin jar and your plugin's proper name (see the Template below) as this will increase the chances of someone finding your plugin through searches.

Next, you should display a clear current version number so that server admins can easily figure out what the current version is (even though this is already covered by your title).

Then, and this is probably one of the most important parts, you should properly describe what your plugin does and how to use it. Far too many plugin releases have little to no information provided, leading to myself - and I'm sure many server admins - skipping over it as it (maybe unfairly) demonstrates a lack of care on the plugin developer's part and I wouldn't want to entrust the future of my server on such a person.

Following the description, download links to both the plugin itself (and some mirrors, if possible) along with the source (if applicable) should be provided.

Though doing this may take some extra work, time and effort on your part - a familiar template for releases increases the possibilities of prospective users knowing exactly where to find a certain piece of information about your plugin, as all plugins will be placing the same type of information in the same place.

After all this, you should include a detailed changelog (the last 3 or 4 versions with the full changelog in an external file perhaps?) and maybe a todo list. The changelog should show at least the last two versions, with the full changelog available through a link or a spoiler.

Template

Code:

TestPlugin - The Test Plugin:
[B]Version:[/B] v0.2
 
This is a description of my awesome test plugin and how to use it.
 
[B]Features:[/B]
[LIST]
[*]My plugin makes cake
[*]And eats it
[/LIST]
Download The Test Plugin
Source Code
 
[B]Changelog:[/B]
Version 0.2
[LIST]
[*]Added the ability for the plugin to eat the cake it makes
[/LIST]
Version 0.1
[LIST]
[*]Releasing my awesome plugin
[/LIST]

Demo Template

 

Here's how you edit your thread title:

1. Open your thread.
2. Click "Thread Tools":
   
3. Click "Edit Thread":
   
4. Edit the title!
   

This can also be done from the forum view/thread list page:

1. Next to your thread, click the small grey "Edit" link:
   
2. Edit the title!
   

 

FAQ
How do I get my Plugin Submission approved?
The Plugin Submission system is manually managed by the Bukkit Community Staff. We try our best to go through the plugin submissions and approve/reject them every few days. When we reject your plugin, you will generally be told what is missing or what part of your submission does not meet our requirements. However, if this isn't the case you have likely not met a number of the requirements and we'd prefer it if you read through thePlugin Submissions/Release Guidelines and find out what is missing yourself.

How do I become a Plugin Developer?
The Plugin Developer system is manually managed by the Bukkit Community Administrators, so it could take a while for us to get to adding you to the Plugin Developers group - but we will get around to it! Currently the criteria for becoming a Plugin Developer is that you release a plugin that meets our Plugin Submissions/Release Guidelines and that it is used by a few people but this subject to change without notice at any time.

Does everyone who contributed to the plugin get a Plugin Developer title or just the person posting a release?
Up until now, I've only been giving out the Plugin Developer rank and title to the person posting the release (the lead developer in most cases). However, I've decided that we could give out the Plugin Developer rank to everyone who contributes a significant amount to a release/project, provided you specify their name and a link to their profile (you can use the Username BBCode) in a Credits section within your release post. If you've done this, report your release post and we'll get around to dealing with it.