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

Discussion in 'BukkitDev Information and Feedback' started by pyraetos, Feb 15, 2012.

Thread Status:
Not open for further replies.
  1. Offline

    pyraetos

  2. Offline

    Sanzennin

    So, the file's title cannot contain anything else than the version of the file? Or can it contain other logical stuff, like the project name with the version? Like, "Skillz v5.5"? Just asking since it isn't stated clearly in the guidelines that having the project name in filetitle isn't allowed, just that it isn't required. However, a mod just sent me a PM telling I should remove the project name from all the file-titles of my already approved files/projects.

    Thats just how I understood the guidelines, pardon me if I am reading it wrong. :(

    What about if there was a Skillz api? Would that be "Skillz api v1.0" or just "v1.0"? Or "api v1.0"?
     
  3. Offline

    chaseoes Retired Staff

    Just the version with the title. For the API it would also be just "v1.0". Also, it is clearly stated in the guidelines that having the project name in the title isn't allowed, since it provides a specific format.
     
  4. Offline

    Sanzennin

    Oh, I must've missed that page. The guidelines I was referring to was the one pyraetos posted.

    Though it did bring up a few more guestions:
    Wouldn't having a project with files in order like: "v5.5" "v1.0" "v5.4" "v0.9" "v5.3" "v0.8" be confusing? How would they know its the api? Open the files page and look at the filename? Is filename allowed to have "api" in it?

    Also, isn't that page conflicting what pyraetos just said about the filename? Seen the link you provided says the filename must contain the MC version and Bukkit version in square brackets?
     
  5. Offline

    NeatMonster

    Sanzennin chaseoes

    After a talk with NuclearW, it has been decided that we will tolerate the PluginName vVersion format, even if the correct format is vVersion. Thank you for your understanding.
     
  6. Offline

    Sanzennin

    oh, thank you, and sorry to bug you guys about it. It just seems to be what a large portition of devs like doing.
     
    NeatMonster likes this.
  7. Offline

    chaseoes Retired Staff

    Oh come on, seriously? :(
     
    rtainc likes this.
  8. Offline

    NeatMonster

    Yep, feel free to PM an Administrator if you doesn't find it fair.
     
  9. Offline

    Wolvereness Bukkit Team Member

    NeatMonster oh hey there!
    /me scurries to go rename his files back.
     
  10. Offline

    NeatMonster

    Sorry about that. :oops:
     
  11. Offline

    Gravity Retired Staff

    Also note that if a plugin is discontinued or falls inactive you are free to update it or post a new "refurbished/updated" version to BukkitDev, but just because your favorite plugin isn't update the day of a new RB does not mean you can post a new or "forked" version. I see projects a lot where people just decided to fork a plugin and make it "more stable" or include some new feature. Instead of posting and maintaining an entirely new project, just ask the author to include it in their project or make a pull request if they have github.
     
    Don Redhorse likes this.
  12. Offline

    pyraetos

    If you do have to continue someone's plugin with a fork, make sure you can prove you have the author's permission AND that it falls under the license he chose. Both these things have to be true for a submitted fork to be accepted.
     
  13. Offline

    LinkterSHD

    Thank you so much for this really helpful guide. It helped a lot
     
    pyraetos likes this.
  14. Offline

    Gravity Retired Staff

    Please snip the post there's no reason to quote the entire thing..
     
  15. Offline

    mbaxter ʇıʞʞnq ɐ sɐɥ ı Retired Staff

    And done. Senators24 next time if it's HUGE, just quote a bit :D
     
  16. Offline

    LinkterSHD

    if sorry. i will do that next time
     
  17. Offline

    XMdead

    I believe you need to add the following to the guidelines:

    1) A clear indication of whether for-pay plugins (or plugins with both free and for-pay features) are allowed.
    2) A clear indication of whether anti-tampering or other security features are allowed. Specifically features intended to support the legal rights of authors that used a license that protects their rights to the code and restrict permissions to modify.
    3) Any other obvious and non-obvious rules that file reviewers follow in determining whether the code is acceptable or not.

    I recommend this because I found my plugin rejected for the reason "This is absolutely not allowed!" with no further explanation. The plugin will eventually be enhanced with a set of premium for-pay features. As such it must be possible to identify pirated uses of the premium features, have automated security, and other features to catch and prosecute pirates. The section in question is an early form of this, by reporting the plugin's presence to me (and me only) when I login to a server.

    The way I see it either the reviewer goofed or there are unpublished guidelines being applied during the review process. Either way... the rules need to be clearer.
     
  18. Offline

    pyraetos

    These recent changes to the original post should help clear things up, thanks.
     
  19. Offline

    XMdead

    Yes, that cleared things up some of the questions.

    Does the rule forbidding for-pay plugin features (in addition to the free features) apply to using the CraftBukkit library or only to publishing plugins in the Bukkit site?

    For example, can a for-pay or hybrid free/for-pay plugin (that is NEVER posted or mentioned in the Bukkit site) be made using the CB library? Does the CB library allow such use?
     
  20. Offline

    TnT Retired Staff

    You can charge for plugins as much as you like. You cannot advertise such "for pay" plugins on bukkit.org.
     
  21. Offline

    Gravity Retired Staff

    That should be "as these have NOT been checked for safety..." :)
     
  22. Offline

    pyraetos

    Thanks, fixed.
     
  23. Offline

    pyraetos

    Please note that when using BukkitDev, you are not allowed to sell plugins or services, or advertise jobs, plugins, services, or anything else for real world money. This includes comments on all pages, forums, conversations, and everything else.
     
  24. Offline

    Gravity Retired Staff

  25. Offline

    pyraetos

    Please read the new section on auto-downloaders.
     
  26. Offline

    Gravity Retired Staff

    So the auto-updating policy right now is a bit annoying because BukkitDev doesn't have a static link to the latest file. People have asked if they can make life easier by reading the latest file link from a remote file they have set up on their own server, that is updated with each release. For example, you upload a new file and then update a .txt file on your own server that points to the new file's url, and all the distributions of the plugin read from that to get the new update link.

    The answer to that question is sadly no, because it presents the same problem as the things we are trying to prevent: that url can be changed later to point to a malicious file, and nobody would be the wiser - we don't have time to check back with that file every day to verify it's integrity.

    However, a good compromise is this - instead of providing the entire url to the BukkitDev file in your text file, simply put the dynamic part in. For instance, if the new file's URL is http://dev.bukkit.org/server-mods/anticheat/files/9-anti-cheat-v1-3-3/ just put /9-anti-cheat-v1-3-3/ into the txt file, and then in your actual plugin you can append that to the static part of the url, thus forming the appropriate place to connect to. Pseudo code:
    Code:
    String file =  //connect to your site here to get the appropriate update location, ex. /9-anti-cheat-v1-3-3/
    URL bukkitURL = new URL("http://dev.bukkit.org/server-mods/anticheat/files"+file);
    //Download the new file using bukkitURL as the location
    Basically this means that dev.bukkit.org is hardcoded in, and the system will never be able to download an update off-site, but that it won't have to do page-scraping or RSS reading or something silly to get to the newest file.

    I'm hoping this adequately explains it - if you have a question just ask. For anyone wondering, we do recognize the inconvenience of the rule in it's current state. However, seeing as security is at the front of every decision we make, it's something we had to go ahead and enforce, despite the current lack of tools that can make it easier for people to auto-update (like a static url, etc). Our second step will be to push as hard as we can to make these things available to you, but the timeless saying still goes here; safety first. Hopefully this post makes it a bit more trivial to implement a safe and policy-compliant auto-update system.
     
  27. Offline

    coldandtired

    Addresses like that don't point to the actual files, only the page with the file description.

    http://dev.bukkit.org/media/files/599/557/AntiCheat.jar would be the direct link.
     
  28. Offline

    TnT Retired Staff

  29. Offline

    coldandtired

    Doing it that way avoids file screening completely, unless you're prepared to upload the file and then wait until the file is approved before changing the text file. In that case it's a far worse solution than the "silly" RSS scraping.
     
  30. Offline

    TnT Retired Staff

    That's what should happen.
     
Thread Status:
Not open for further replies.

Share This Page