Safeguard Versioning Policy

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

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

    EvilSeph

    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

    Sadorhael

    While I kind of understand where this thinking with the Safegurad is coming from, you are pushing large bits of your own community away. That is sad for you, for all us server admins and not least for the future of Bukkit. Some of the most popular plugins have already moved away from Bukkit (like Heroes and Towny), which makes Bukkit much less relevant for server admins like myself to look at Bukkit ever again.

    I am afraid your decision to finalize classes and being so strict is the first step on your doom. Please reconsider and make up with the developers that left already. For the sake of all your server admins.
     
  3. Offline

    xXSniperzzXx_SD

    This whole safeguard will only effect a handful of plugins, and for the ones it does (Like mine) It's not that much work to update every version. It's the exact same as before, you update, test then upload. And if that is to much work for them then they shouldn't be a developer anyways. Yes i know some great plugins have stopped, But this safeguard will protect servers from buggy plugins that will corrupt data.
     
  4. Offline

    phillipkdick

    a handful of plugins... yes, but in this handful have towny and iZone, two of the most populars plugins for protect cities and houses, i dont tell this, curse tell it when this plugins are in their bd, and you can tell it to the servers admins when go to update her server and see this... their protect plugins have disappear of bukkit...

    and now?... so sorry, but your bukkit 1.4.7 makes me java fails and crash the server... great core, and isn't for safeguard and no bukkit plugins, only for your bukkit core, java crash. And in the future? 1.5... no towny, no iZone, and a "handfull" of plugins less... nice, all servers with factions or essentials protect, its a joke for aprils fool?

    in 6 months the only time was corrupted the mysql bd, is when you put the "safeguard", the only moment, the only time, the only anything, is when you active the safeguard... iZone dont make me never any mistake, and i think, techguard dont want to crash servers and corrupt bd's... the only time when this plugin fails and affect all of the server is when you put the safeguard in bukkit... coincidence?... i dont think so

    you want to have all of production of plugins, dont have competence with others minecraft cores, and no have any problem because, "this plugin broke my server"... but this... is absurd. And this "politic" change, or me, and so sorry, search another minecraft core... is stupid for your part... it's the second time in one month, and i think, isn't the last...

    i put the plugins of i want in my server... and if one of this plugins are "corrupted" i put this under my responsability, and dont need any "father" to tell me, this plugin is ok, and this not... Put in the "server.propierity"... SafeGuard=true or false... this, for me... its more intelligent than put yes or yes.

    nice work bukkit, nice

    ed: i know... my english are piece of shit
     
  5. Offline

    lDucks

    It
    It seems like your problems are not wtih Bukkit.. You're blaming Bukkit for issues with your server that are completely unrelated.
     
    TnT likes this.
  6. Offline

    TnT

    phillipkdick
    Java crashing is indicative of an OS or hardware issue, which would also easily explain your database corrupting. You have simply ran into a co-incidence. I strongly urge you check out your OS/Hardware to ensure it is running in peak condition. CraftBukkit doesn't cause a Java crash.

    Towny requested to be removed from dev.bukkit.org despite our best efforts to help them through any transition to a project compliant with the policies that all other developers with projects on dev.bukkit.org abide by.
     
  7. Offline

    xXSniperzzXx_SD

    phillipkdick
    Ever heard of Precious Stones, WorldGuard etc, there's more then just 1 protection plugin...
    And putting it in the server.properties would be nice except there's one flaw... It will be even harder for us devs, because it's imports which you can't really toggle an import. And what if multiple versions of CB want to use the same version, so you'd need different imports, which just makes things more complicated. So you're gonna have to deal with it. Plain and simple.

    And ya like everyone else has said, most of your problems aren't bukkit related.
     
    EvilJackCarver likes this.
  8. Offline

    KittyKatt

    I dont understand, will I still be able to add third party libs like Apcache Commons Net 3.2 to my plugins?
     
  9. Offline

    Malzbier

    Im no plugin Dev but im a coder in general(CSharp).
    I like the idea of forcing the Devs to use the propper api.
    That will save the most server owner Big time if the do not have to Check ever plugin if its crashing the server or not.
     
  10. For many cases, the proper API does not exist yet :), though it has become pretty rich up to now. Still specification of what things do is missing in so many places, also leading to strange discussions about what is to be called a bug etc.

    Not sure about that numbers on "big deal", "big time", "saved time", "easy to update (and maintain?)", yet...
     
  11. Offline

    D3matt

    Then there should be an option so experienced users can disable it. Forcing it on everybody because of a few bad eggs is stupid.
     
  12. Offline

    mbaxter ʇıʞʞnq ɐ sɐɥ ı

    You can't... disable it. That's not how it works.
     
  13. Offline

    Flenix

    *Spoutcraft, and it's running 1.4.7 so not really outdated :p At any rate it's considered Legacy now and is being faded out over the full project Spout.


    Surely if it was written differently that would be possible, or even just a forked project? I don't know how much code it entails so can't really say for sure.

    Anyway, on to why I'm here.
    I've seen various supporters saying that it hasn't affected many people negatively and so on - I can say it has. The only way I even knew of this change was due to the amount of backlash I've seen around other forums of developers leaving BukkitDev and turning to those other forums (which I'll leave unnamed)

    I can see the purpose of the idea, and for the new/younger people who decide to set up a server, I can certainly imagine it'd be good. But, it is quite limiting for those who know what they're doing. It may not prevent many plugins working automatically with each update, but those it does are generally the bigger ones (For example MagicSpells has been a core part of my server right til I shut down last month... and that has always had a similar system built in directly anyway to disable those features...)

    To sum up, I think it's a good idea, but really badly implemented. It NEEDS some way of disabling it, else all you're gonna do is piss people off. I know that might require a bit more work, but surely if it's for the good of the community as a whole it'd be worth it in the end.

    Just stating my opinions after reading both this thread and the views of those who oppose it. I left Bukkit before this was even implemented for other reasons so it doesn't actually affect me directly at all.

    EDIT: I do think it's quite sad how many great projects are disappearing from BukkitDev. Just looked and Towny really is gone... One of the best plugins to ever exist on Bukkit (and Hey0 for that matter)
     
  14. Offline

    TnT

    Flenix
    Towny voluntarily left over something completely different. We have seen some developers leave due to this, but as far as I know, their projects have been handed over to others willing to take them up.
     
  15. Offline

    LlmDl

    Flenix
    Towny doesn't use any NMS/CB code so it isn't really affected by the safeguards. As TnT mentioned, it was completely different.
     
  16. Offline

    Kainzo

    Ultimatey, I agree but the current setup forbids it. It's not easily possible in the code.
     
  17. Offline

    Flenix

    Ah fair enough. I just know it was there and now isn't, so I assumed they were one of the flock :p
    I know it always had version checking too so assumed that they were using NMS code and it was a built-in safety feature. Maybe it was for something else then :p
     
  18. Offline

    LlmDl

    We started using version checking so people would update their craftbukkit, and not just Towny :)
     
    Flenix likes this.
  19. Offline

    Sadorhael

    I'm sorry but it doesn't help at all that it is only affecting "a few" plugins. (I'm not even convinced that is true, btw.) But the point is that it is a political change that have pushed great developing communities away from Bukkit. Heroes and Towny are two of the most useful plugins out there, and them leaving Bukkit have forced me to switch core as well. The actual plugins are much more important to my players that what core I use.

    I am a programmer and systems designer by trade and I know my way around Java code. Like I have said before, I understand why it is tempting to force your plugins developers to abide by your standards, but this isn't a single conventional development project. It's a community where people from all over the world are contributing in ways they see fit. Therefore, if you are being too strict in your policies, you are destroying your community, at least diminishing it by a great deal. As far as I can see in forums around, Bukkit's reputation is starting to decline because of this decision, and I think it is a pity to throw away the great community you have build up.

    PLEASE at least make this Safeguard possible to disable in some config file. And I strongly encourage you to try to convince the developers of Heroes, Towny and other popular plugins to come back.
     
  20. Offline

    jkcclemens

    Personally, I rather enjoy the safeguard. It discourages beginning plugin developers from delving into NMS/CB internals, and it keeps servers from being harmed unintentionally by NMS changes when Minecraft is updated. There's no reason to be angry about the safeguard; people should be grateful.

    It also encourages people like me (lazy) to invest time in switching completely over to Bukkit API (instead of using CB/NMS) so that plugins don't need to be updated every time the safeguard is. While I think there are some legitimate uses for NMS, most developers shouldn't end up using it. The larger plugins that call on it will surely update, and the smaller, inactive plugins using it should be replaced anyway.

    This is just another step up in Bukkit's history.
     
    drtshock and troed like this.
  21. Offline

    LlmDl

    Sadorhael Towny left dev.bukkit.org because of the no-external-links rule they added to the site. We have a new homepage that you can find by googling us. The safeguard-versioning did not affect Towny because we don't use NMS/CB code.
     
    lDucks likes this.
  22. Offline

    Sadorhael

    Thank you for that information. I find it equally sad to impose such a policy.
     
  23. Offline

    lycano

    Kinda offtopic but i dont understand why someone would not make a new towny from the ground up using existing plugins instead of trying to re-code Towny.

    From my point of view Towny can be rebuild with a combination of RankedPermissions promote/demote system (PermissionEx) and GridLike Protection (WorldGuard).

    @ Topic
    This all does not depend on NMS nor CB imports just plain API.
     
  24. I think in the long run this is great simply to stop authors using this code! However I think bukkit needs to include more of the craftbukkit methods in its api. There is many a good feature unavailable with the official api :(. Long live bukkit!

    How do i request this?

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: May 30, 2016
  25. Offline

    dreadiscool

    Most of these steps are easy, except for d. We all know how long it takes for code to be accepted on BukkitDev ;o

    And I'm guessing if a plugin's using NMS code, it's not going to be a small one.

    "Craftbukkit doesn't cause a Java crash"
    I lol'd

    I don't mean to be "that guy", but I don't really like this new safeguard feature. It may be helpful for newer server admins who don't understand, but there should be a way to disable version checking. Maybe, instead of renaming the package constantly, you could store a 'version' number inside bukkit, and have developers include a range of bukkit version numbers in their plugin.yml

    That way, if a plugin's version doesn't match a version the current version of the bukkit server, it can be auto disabled. Because of this, it's easy to disable version checking for server admins who know what they are doing with plugins.

    I myself don't update to newer version of Minecraft without extensive testing of any plugins that run NMS calls, and I'm sure that other people do the same. I don't feel the need for version package names. I don't need Bukkit to babysit me.

    If server owners are smart enough to go into the plugin.yml and edit the version name to include an untested Bukkit build, it's completely their fault. They should be smarter than that...

    If plugin developers are including bad builds into their accepted version range, then server owners should blame the developer anyway. It's not like it isn't possible for them to accomplish the same thing with reflection anyway.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: May 30, 2016
  26. Offline

    TnT

    I have yet to see a Java crash caused by CraftBukkit. I've seen them caused by bad hardware or bad plugins, but not from CraftBukkit. You can lol all you want, but until you can prove otherwise I'll stand by my point.

    A version number inside of Bukkit makes no sense. This is an issue tying into CraftBukkit methods, not Bukkit. We have already covered that point in length.

    Before this commit it was much, much harder to track down an offending plugin. Now its rather easy. I don't need to be babysat either, but I do enjoy having plenty of information at my disposal to troubleshoot an issue - this commit provides that information.
     
  27. Offline

    dreadiscool

    Before I moved away from Bukkit, almost all recommended builds on version 1.4.7 would crash with exceptions like failing to tick entities. The moment I switched away, not only did I notice a huge performance gain, but my servers can run for long periods of times without crashing (I can cross 24 hours of straight uptime now!)

    I don't know what kind of stability testing you do on Bukkit, but I can assure you that on production servers, there are many crashes on the bukkit platform.

    Edit:
    You may not have seen crashes on your specific tests, but the bukkit staff here seem to be growing more and more oblivious to what the community is saying, as can be seen with the whole backlash with the forced version names.

    Bukkit staff can continue to believe that the changes they are making are for the "good of the community" and that what they are doing is helping it. And they can continue to "stand by their point" unless [we] "... can prove otherwise", but honestly, I can't be arsed to go through tons of logs just to prove this to you.

    I've made the switch, and others are going to as well, while you guys keep pretending that everything's dandy.

    Please tell me why this doesn't make sense. There are already version names inside /version. The new version checking system would be disable-able (is that a word?) unlike renaming package names. Regardless of whether or not plugins breaking is an issue of tying into CB code, it should not matter. This new system should be disable-able. All I did was offer a compromise to both sides.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: May 30, 2016
  28. Offline

    TnT

    That was a plugin caused issue. It was actually a plugin that used NMS code that caused your issue. You stated you tested your plugins but this very quote contradicts that point.

    I often leave my 1.4.7 server running for days.

    So we have to take it at your word, based on your opinion which has no facts to back it up, and make changes based off that, verses making changes based on facts and gathered evidence? Doesn't seem very logical to me.

    Read this post. Read the commit that started this discussion. Its all been stated before, I don't need to state it again because you "can't be arsed" to read the discussion.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: May 30, 2016
  29. Offline

    mbaxter ʇıʞʞnq ɐ sɐɥ ı

    That's not a jvm crash, that's a CraftBukkit crash. Big difference. And most of these crashes are caused by bad plugins, causing either instant crashes or map corruption that comes back to haunt you later.
    I don't understand where this aggressive attitude is coming from. Nobody's ignoring crash reports or other bugs, nobody is ignoring community input.
     
    drtshock likes this.
  30. Offline

    dreadiscool

    I was using 11 plugins, all of which I wrote, none of which used NMS calls

    Also, mbaxter I'm not trying to be aggressive, I'm just trying to show you that this new version name thing does more harm than it does good, and offer a solution as to how the best of both worlds can be implemented.
     
  31. Offline

    TnT

    A solution we have already said, multiple times, would not work.

    Then you would not be affected by this safeguard in anyway, and are here discussing something completely irrelevant to the topic at hand.
     
Thread Status:
Not open for further replies.

Share This Page