Safeguard Versioning Policy

Discussion in 'Bukkit News' started by EvilSeph, Jan 16, 2013.

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


    To protect servers against incompatible plugins that have been developed using the unpredictable and volatile Minecraft code (which we’ll be referring to as “non-Bukkit API plugins” from this point onward), we made the difficult decision of implementing a controversial safeguard into Bukkit. This safeguard forcefully disables non-Bukkit API plugins from running on your server if they have not been verified by their developer to work with the Minecraft version on which your Bukkit server is running. As Bukkit has no control over what changes are made to Minecraft itself, developers should not be relying on its code in any way, shape or form.

    Without this Safeguard in place, running non-Bukkit API plugins on your server had been putting it at risk of instability due to unpredictable behaviour. With the Safeguard in place, developers of non-Bukkit API plugins now have to responsibly check that their plugin works with each Minecraft update, then upload a tested version before the plugin will be able to run on your server.

    When we first implemented the Safeguard, the intention was to forcefully disable incompatible non-Bukkit API plugins with every new Minecraft version, no matter how small the changes. However, since we have the freedom of a flexible release schedule (which Mojang does not), we're usually able to fix bugs faster than Mojang can release Minecraft updates, often removing the need for us to update Bukkit and trigger the Safeguard needlessly (as was the case with Minecraft 1.4.7).

    As such, we're making changes to when we trigger the Safeguard (implementing a versioning policy): instead of triggering the safeguard with every Minecraft update, we will only be triggering it when necessary. This means that non-Bukkit API plugins will only break if a Minecraft update or a rename update has altered the code, instead of with every Minecraft update. As a result, with a Minecraft update like 1.4.7, non-Bukkit API plugins would not break unless we've had to alter the code with a rename update (which we've done for 1.4.7).

    The technical meaning behind this change is: instead of classes being named "name.of.class.v1_4_6", we will now be following a versioning policy of "name.of.class.v1_4_R1" where "R1" is the internal counter for either Minecraft or a rename altering CraftBukkit or Minecraft code.

    This new Safeguard Versioning Policy will allow us to keep up with Minecraft updates without needlessly triggering the safeguard and breaking non-Bukkit API plugins when we've already fixed all the issues the Minecraft update addresses, while still protecting your servers from running unchecked and untested plugins.
  2. Offline


  3. Offline

    Wolvereness Bukkit Team Member

    TL;DR: The package name (breaking) wont always change with each minecraft update.
    jjacobson likes this.
  4. Offline


    That's awesome, thank you!
  5. Offline


    I've been running my server for a year with no safeguard and my server is as stable as ever! And I have plugins that are backward compatible so I'm not worried about using a safeguard but it's nice to know that it is there if I choose to use it or not.
    Kainzo likes this.
  6. Offline


    Cool! All I need to make all of my plugins completely API is a LivingEntity.walkTo() and possibly and Entity.setSpeed() :D
  7. Offline


  8. Offline


    • All caps posts are not allowed
  9. Offline


  10. Offline


    Really glad to hear this. IMO this is a much better alternative than updating every single MC update.
  11. Offline


    OK, I'm sure we won't miss you :p
    ferrybig, 1mpre55, fromgate and 3 others like this.
  12. Offline


    mrrt and MrBluebear3 like this.
  13. Offline


    That was really your clincher? "I wish you bad luck"?
  14. Offline


    Yeppers, I think this is pointed at the server owners who are a bit inexperienced and a bit too trusting of plugin developers to be doing the right thing.
    grid21 likes this.
  15. Offline


    I don't develop non-bukkit api plugins, but I run some of them on my server. As a result of this patch I have stopped using bukkit. If I was a non-bukkit api plugin dev I am sure this safeguard would be a big kick in the balls.

    This is like forcing all of your employees to clock in and out for even their 10 minute breaks because 2 or 3 of them are late to work.
    phillipkdick and vgmddg like this.
  16. Offline

    mbaxter ʇıʞʞnq ɐ sɐɥ ı

    Takes me a few minutes to
    a) Open up the classes that call non-bukkit methods/classes
    b) Check the minecraft internals, make sure everything's still the same (Or change my code if it changed)
    c) Update references
    d) Push to git, compile, submit to bukkitdev.

    Nothing more than a couple minute experience that is pretty much mandatory with or without the safeguard since these methods/classes are volatile.
    jjacobson likes this.
  17. Offline


    The first time I found out about that changing package name was when I was trying to do something with books. To deal with it, I made a book util class with every class dynamically loaded with package name determined by the string returned by server.getVersion() and all method calls done by reflection. It worked great but I felt bad. Then I found the item meta and it revived my faith in Bukkit API.

    I used to write SSP Mods, and the reason I switched to Bukkit is that I feel it has a real API. Bukkit has given me a very good experience and I wish it will get better by maintaining the consistency of development.

    Hail to Bukkit!
    1mpre55 likes this.
  18. Offline


    Oh ok that makes sense. I've had a good year of experience and I've had my bugs but I know what to look for.
  19. Offline


    For being a news post, this has a lot less posts than I'd expect.
  20. Offline


    Of the 115,000 servers that run the Essentials plugin, 97% run CraftBukkit.

    That is over 111,000 servers running CraftBukkit. 85% of those are running builds that include this commit.

    Now, please, backup your statement with facts, as the statistics don't reflect your opinion.
    mrrt and OPJewelz like this.
  21. Offline


    Oh snap
    GateKeeper258 likes this.
  22. Offline


    I want to know what the "unknown" servers are..
    Deleted user likes this.
  23. Offline


    While I understand and support the reasons behind the safeguard, some takes-5-minutes-to-write reflection code can bypass it entirely.
  24. Offline

    mbaxter ʇıʞʞnq ɐ sɐɥ ı

    And when it's found that a plugin using such techniques has crashed servers, that author is quickly known as utterly incompetent.
  25. Offline


  26. Offline


    I do know the difference. Your opinion is based on unfounded speculation. My statement is based on facts.

    Am I not allowed to debate your points because I have an admin tag? What part of my post was disrespectful? If I attach "In my personal opinion" in front of a clearly incorrect statement, does that mean no one can debate my statement? Good sir, it is you showing disrespect by trying to silence my statement and calling me disrespectful in doing so.
  27. Offline


    How is it determined if an update will trigger a version change?
  28. Offline


    Cool, sounds good.
  29. Offline


    I honestly hate the safeguard. While my plugin use only Bukkit code, I own a server, and with every update, half of my plugins will be guaranteed to break. It takes quite a while for some to update, as some devs are a bit inactive. If the Bukkit API provided all of the methods that so many plugins need, we wouldn't need NMS code. I'm not asking for every single method ever imported from NMS to be imported, just the major few that are preventing a lot of plugins from switching over.
  30. Offline


    The problem, again, is that NMS code is changing rapidly, much more so than ever before. This was not how things used to be with NMS calls, and things which could previously be relied on can now cause damage to servers.

    There really is no reason to be upset about this except that BukkitDev might take some time to approve your changes, but that is being dealt with to minimize impact.

    I think the outcry from developers who are forced to examine their code when an update happens pales in comparison to the backlash that would come from hundreds of server owners who's maps and backups become invisibly destroyed over time.

    That being said, if there are API calls in Bukkit that you need/want and do not have - write them and submit a pull request! The Bukkit team is good, but they can't do everything on their own. Bukkit is free, and if we can't donate money (not always an option - I certainly would if I could!), then donate some time and some design skill.

    As for server owners being inconvinienced by waiting for non-API plugins to update - this is the risk you take when using such plugins. They may be really cool, but there is a price to pay, and you should keep that in mind. Switching to another project like Forge or Spout isn't going to make the NMS issues go just won't get any warning about them (unless they have implemented similar safeguards; I don't really follow those projects so I can't speak for them).
    rmh4209 likes this.
Thread Status:
Not open for further replies.

Share This Page