Guidelines: How to get your submissions approved. (Updated: March 16, 2014)

Click Here for the most recent updated version of the Guidelines.

When a major change is made to the guidelines, we will post here.

 

Which, as I said, is not much of a solution. Three steps instead of one.

 

It may not be an elegant one, but it is the one presented at this time. I think that is preferred to not having any auto update mechanism.

 

Okay, but why is this method being presented? It requires three steps and the dev to host his/her own files.

RSS, on the other hand, is specifically designed to share updates easily. That's its whole purpose and the reason it uses XML. Using this requires one step and no dev-used files and yet is described as "silly".

 

You can do it whatever way you want as long as you are putting yourself in a situation where a file could be downloaded that is not from BukkitDev. If you think what I said is stupid, then find your own way.

 

But even with your way a malicious file could be uploaded. It's allowed as long as the malicious file comes from BukkitDev?

 

That's the entire point of this rule: we manually decompile and review every single file that's uploaded to BukkitDev, and then check it again with automatic systems that will detect malicious usage of the Bukkit API. Why would we be enforcing all this if BukkitDev was not safe..?

 

I already use RSS for it. It's easier and safer (the RSS isn't updated until the file is approved, but the other method requires the dev not to update the text file until the file is approved).

Which is why I asked why the more difficult, less safe way is promoted.

 

Because it's easier to understand. Telling people to parse RSS isn't really the best way to help them understand, if you want to do that it's your choice, with a bit more knowledge it's probably better, however it's easier to explain to people the other way.

Also, using the RSS means that file will only ever be able to download the newest update. Arguably, that's the only file you will ever need, but it's good to have the foresight to have it be dynamic and download a specific file on BukkitDev instead of the newest one in some scenario where that would be needed.

 

I see the problem the other way around.

Dev uploads version 1.7 to BukkitDev.
Not wanting to annoy the mods he doesn't update his latestversion.txt until the file is approved by the BukkitDev team.
The text in the latestversion.txt is "/599/557/AntiCheat.jar" (for example).

So far so good, but because the dev has chosen to wait for approval he/she cannot trust what the latest file is at any time. "/599/557/AntiCheat.jar" could be the latest version, or it could be an older version because the file has been approved and downloaded before the text file has been updated.

Suddenly the simple text file has to store more info to be read to determine whether the link it has is indeed the latest file, and I think is now more complicated than the 5 lines needed to parse the RSS.

 

You can use the RSS. You can use the method h31ix suggested. Both are acceptable, if you wish to use the RSS, go for it.

Remember, it is up to the server admin whether he will blindly accept the updates or not.

 

TnT I know that. I was simply pointing out that the way @h31ix's method is written on the previous page won't work as it will cause the problem I just posted.

 

Because if you upload a file it can still be downloaded from it's direct link without being approved first.

 

I prefer to just use craftbukkituptodate as that reminds me and downloads the change log the last thing I want is it to auto update.

 

Well first of all there's no point uploading something malicious to BukkitDev. You're going to get caught, and second of all we know; we're going to fix that.

 

I have recently fallen foul of this auto updater rule and had one of my plugin updates rejected as a consequence. Since my last update was queried but later approved with the auto updater, I assumed that it was not an issue; especially since I could not find any details about plugin guidelines for submission on dev.bukkit itself. Details like this thread should be on dev.bukkit, not placed in a forum where people uploading will not see it.

Regardless I have a number of thoughts on this policy. Firstly if a server administrator is seriously concerned about the security of their server they should only use plugins for which the source is available. Many plugins are available on dev bukkit which have no source available whatsoever. I personally run a policy that I will not have any plugin on my server for which the source is not available.

Secondly you ask use to avoid using systems, and cripple useful functionality, which are tried and tested (such as Maven, used by Bukkit itself) and switch to parsing RSS feeds because you still have not got a system in place to provide a static url for the latest version of a plugin. This was something that I raised almost a year ago as an issue.

Having seen zero progress on this issue I developed my own. The solution posted about regarding manually hosting, and updating, a text file on a separate server to point dev.bukkit.org creates more work for developers which is completely unnecessary and will create mistakes. I seem to remember that dev.bukkit was promised to handle all this for us when it was announced last year and yet very little has materialized.

At the moment I push an update to my repository and users can be notified and download it if they want. The system you are asking me to adopt is to check if there is an update available, update a text file by hand since the addresses are not predictable (or write a script to parse the RSS feed and then provide the link), and upload the plugin to dev.bukkit and wait for it to be approved. This is more effort on everyone's behalf for very little gain other than driving traffic to dev.bukkit.

I also assume APIs such as bukget which are designed to work around this lack of functionality would also fall foul of the rules, since the servers providing the access could return links to wherever they like.

Thirdly it is a policy which is selectively being applied depending on the popularity of your plugin or who you are. I know of several high profile plugins which have auto updaters or download additional libraries or resources which are still approved / being approved as we speak.

I think the best compromise in this circumstance is to allow plugin developers to ship automatic updaters but turn them off by default. This means that if an administrator trusts the plugin author they can re-enable it and have the joys of automatic updates. If they don't it would notify them instead, from details held on the developers server or dev.bukkit, which is currently allowed under the rules. Like TnT said, it should be the server administrators choice when configuring the plugin if they want updates, not dev.bukkit.

This whole policy needs more carrot and less stick. The changes you are making creates more work for me and reduces my enthusiasm for contributing to the bukkit community.

 

grandwazir
You are right, it creates more work for you. I fully understand it is not very clean to do automatic updates with this method. However, this is the situation we must deal with because the alternative is dangerous to the community. We took measures to enforce this auto update policy due to dangerous code being made available through the use of auto updater plugins/methods. I do not want to sacrifice community safety to make the life of people using auto updater methods easier.

To be clear, we cannot allow updates from offsite. All files updated must come from dev.bukkit.org.

While I agree that server owners should take on some of the responsibility for server security themselves, many will not understand that setting their update option to true allows devs to completely bypass the safety we provide with BukkitDev and potentially compromise the safety of their server. Requiring updates to come from dev.bukkit.org means that every file that gets uploaded via the auto update processes has been checked over by BukkitDev staff. This means server administrators do not have to learn Java to trust the plugins they use are safe from malicious code - which is one of the best reasons to use BukkitDev to find plugins. We have talked with Curse about bringing in a static link to the latest version of the file, which will be implemented as soon as possible. However, due to their major rewrite of the template code to allow for greater customization of Curseforge sites (dev.bukkit.org among those), this change is not going to be instant. We have a large list of features requested, and this is one of those features we would like to see.

If any project is using auto update methods that do not comply, report them and we will work with the authors to correct those oversights.

 

I am intrigued. Is this a perceived threat or something which has already happened? I have made the necessary change to the code to remove this feature although I would like a moderator to review it before I go through the progress of re-releasing all of my plugins again for the change to take effect. I am disappointed that I have had to do this though; the alternative suggested is not useful since I can already check for the latest version easily by pinging the maven repository.

To clarify, would this include additional libraries which are downloaded once such as JBDC connectors for example?

The main issue is I have not seen any progress at all on dev.bukkit since it was released last year. In fact features have been removed (see content formatters, profile linking temporarily, etc). All I hear is things are moving behind the scenes but you can understand my frustration when I say I want to see something tangible and useful.

The really silly thing about the static link, is the functionality already exists. If you click the download button on curse.com for a plugin it does correctly resolve to the latest version. This is not useful for us though since it follows through to a timed redirect page, but still the point stands.

 

I will have someone check it over.

A great deal of changes have been completed. Most of them aren't readily visible, so I understand how this can seem like the case. Some deprecated markup languages were removed, as they contained security holes and the Profile linking was entirely on Bukkit's side.

Linking from the site is one thing, automatic linking without driving any traffic to the site, yet incurring a high cost to provide bandwidth and hosting is another.

 

TnT I am starting to get very frustrated with this and although I hate to air this in public, I am getting very little reply back from the people doing the approving. I have spent a substantial amount of time in my holiday updating my plugins and making the changes that were asked and yet still things are being rejected.

I've had two rejected because they are checking to see if a new version is from my server. It is a completely safe method as detailed in the published source code, and in line with the policy as far as told from another reviewer. It is even a temporary file which is cleared when the JVM closes.

Because they are all based on the same library any changes to it requires me to recompile ALL the plugins that depend on it for the changes to take effect. I have 9 plugins on dev.bukkit each of which takes me 6-8 minutes to recompile, version and then upload. The whole thing is getting very tiring.

 

Handling this on IRC.

 

grandwazir
We will PM you and come to a resolution.

 

Changelog

Aug 3rd, 2012:
Projects:

• Updated "Download Links"

Files:

• Added "Relationships"

 

Changelog

Aug 3rd, 2012:
Projects:

• Updated "Download Links"
• Added "Naming a Project"

Files:

• Added "Relationships"

​

 

Would it be possible for the RSS feed on dev.bukkit to contain a link to the actual file rather the files category. This would make it possible to have compliant auto updaters. The alternative would be to parse the page itself for the download link which would not be that difficult but would still slow the process down.

 

The files page has an rss feed.

 

It does, but there is no direct link to the .jar in that feed.

grandwazir You do have to parse the page, considering you are also downloading the .jar it's probably not going to hurt the total time that much. If it's any use there is an example here.

 

Changelog

Aug 7th, 2012:

Files:

• Added "Plugin stats collection"
• Updated "Auto-updaters and opening URLConnections"
  • Included comment on ensuring a config file option exists

 

About plugin stats collection. I use metrics to collect current users, and it creates a separate folder that lets you disable/enable it. Is that okay if it's not in my configuration but in the other one?

 

That's fine, yes, as long as the system has a way to be turned off.

 

I almost added in a part for Plugin Metrics users. There is a global value, which is sufficient. Nothing to stop devs from adding in a plugin specific version, of course.