Safeguard Versioning Policy

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.

 

You're drawing conclusions based on things I haven't stated. Just because I didn't use any NMS plugins for those tests doesn't mean that I don't use NMS plugins. I run those tests to check if Bukkit is stable or not.

You've got the people that hate the new package names, and the people that suck up to you when they say the new system is great.

EDIT:
Also, I'd like to know, why is the solution I've proposed not going to work? I don't see how this would be hard to implement.

You keep claiming the moral high ground when you guys say you have gathered tons of facts and evidence saying that most people support this new move. Could you please show me some of this evidence before you try to ask me for mine.

 

I said your issue was caused by plugins that tie into NMS. You stated

Now you state

When an plugin using NMS or other CraftBukkit internals corrupts your world (which is what this safeguard prevents) you can't just remove the corruption by removing the plugin.

We've got a vocal minority that dislike this package rename, and a non vocal majority - those plugin developers who do not use CraftBukkit internals, who are indifferent or applaud this change. Read the commit, and this thread.

You refuse the read the main post, or the commit message. You said yourself you don't need us to spoon feed you, so don't expect me to repeat the answers that have already been provided. You really need to start reading, its been covered many times.

Now it is you who is assuming. I said there are facts and evidence that state this was a wise move. Those are also covered by this thread and the commit message that started this off. If you wish to continue the discussion, I suggest you read up about it first.

 

So I have been browsing over the comments on the commit that started it all... And the developers in there raise very, very valid points.

I read the first 100 comments. Literally. I found 1.5 people who enjoyed the commit. mbax (he's bukkit staff, no surprise there!) and the other 0.5 person was asofold, because he seemed to have mixed feelings. I am definitely not going to read the rest of the commits, nor do I have to read them in order to understand that all the developers are screaming at you with these updates.

You claim that you listen to the input of the community. There are well over 1,000 posts on that commit, from some of the brightest plugin developers on there. 99% of them are all saying the same thing: Please revert this commit.

Idiots are going to be idiots. From what I could glean, you are hesitant to add on-the-fly checking of versions inside plugin.yml because server admins would go in and add their bukkit version to the 'acceptable' versions range inside bukkit.yml. So because the server admins do that, then come and complain that a plugin broke, you are going to force all plugin developers to cater to the needs of the idiots?

That's like taking a gun from an armory [download a plugin], pointing it at your face [use an outdated plugin], firing it at your own face [changing the plugin.yml contents to make it work], and then blaming the government [bukkit staff], that the armory [the plugin developer] crashed your server. I fail to understand, if the admins are jumping through hoops to try to run their incompatible plugin no matter what, why should the bukkit staff, or plugin developers be forced to pay the price?

Previously, I agree as mbaxter said, I may have sounded over aggressive, and I want to apologize for that. It's just that, for the love of god, I can't understand why the versioning commit has been added! Previously, people that bought plugins from me would complain of my plugins breaking due to Minecraft updates. After this commit, they complain to me of NCFE exceptions. It did nothing except change the exception that people gave me.

I take great pride in keeping my plugins and server up to date, even recoding critical plugins like NoCheatPlus and libraries like Topcat's NPC library after a release so that I can get a stable production server running just hours after the first dev build for bukkit is released [I keep backups, I'm not THAT irresponsible]. Now, not only do I have to recode these plugins, but I have to go through and replace ALL of the version names.

And I'm not the only one. There are plenty of developers out there who are experiencing the same agony that I'm experiencing in getting plugins out there, all for the sake of that one server administrator, who goes out of his way to bypass a plugin developer's plugin.yml checks and complains when something breaks.

I would also like to know if there are any other reasons as to why the bukkit-version-range implementation inside the plugin.yml is a bad solution to this situation, rather than a package rename.

EDIT: After reading TnT's post above...
1) My test servers run separately from my production servers. I stated that I test with non-NMS plugins. Nowhere did I state my servers don't use plugins that use NMS.

2) The plugin developers who are indifferent about the change because they do not use NMS are irrelevant in this discussion, as they have no stake in the argument, nor do they care enough to make a post about it.

3) Why are the people who applaud this change so quiet? I'd assume that at least more than 5 people would come out and denounce the slew of developers denouncing this change.

4) I have read the main post multiple times. It states that the new versioning policy will prevent old plugins from destroying new servers. I understand that. What I don't understand is why this extremely rigorous method is needed in order to do that. And I repeat once again, why not use on-the-fly checking with a bukkit-version-change tag in the plugin.yml, thus making safeguarding a disable-able feature? To new server owners, the on-the-fly checking does exactly what the versioning policy, and to experienced server owners, allows them to disable the checking if they know what they are doing.

 

Let me know when you've read the remaining 1400 comments.

 

It doesn't take reading 1500 comments when reading 100 will suffice to realize that the developers have stated that they dislike this. I don't understand what reading the rest of them will accomplish, other than further adding to the list of developers who don't like this update.

Unless you've been reading one thing, and thinking another?

I don't quite understand as to why you're calling me out on this, as you've done this in this discussion already. Also, I ask again, what kind of evidence have you gathered? Could I please have a direct answer, seeing as I'm so incompetent?

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

1) First comments out of a set of comments is not a valid sample of comments in the thread.
2) Commenting developers on the commit thread are not a valid sample of developers.

Those happy with a change are far less likely to comment compared to those upset with a change. You can't do a statistical analysis of comments on that thread to determine the community's response.

 

So where did you get your facts? You know, the part where you claim people are happy and all.

Is this how you get away your mistakes?
Step 1: We want to implement a new versioning policy, but we are open to discussion.
Step 2: All of you who commented are not a valid sample of developers, so we are still keeping this new versioning policy, thank you for your comments, we always consider your input.

 

I don't think so. Those 1400+ comments on the commit should have been enough to judge if this feature made developers happy or not.
The Bukkit team already stated that they didn't want to rollback this commit or use an other method in any way, so I guess the developers accepted or declined that and just focused on other stuff again.


@dreadiscool The NMS/OBC plugin developers gave there comment on this commit and the Bukkit team didn't want to change anything of it because they claim its fine the way its implemented now.
What NMS/OBC developers do now at the moment is this:
- Remove all NMS/OBC calls in their plugins (LWC losses a bit performance): LWC
- Change their plugins to use NMS/OBC calls if the CraftBukkit version is valid and if invalid then use BukkitAPI only: NoCheatPlus
- Quit Bukkit plugin development completely or just drop some of the NMS/OBC plugins: NoLagg
- Just develop as it was before but keeping in mind that the plugin will break on every Minecraft update (Some developers don't have that much time so they quit plugin development because of this)

EDIT: Bukkit wont add a configuration option in the bukkit.yml because they kinda want us to force using this "feature". The only way to bypass this commit with a plugin would require a Bytecode Editor and Bytecode Editors are not allowed in DBO/DevBukkit. So yea...

 

Exactly, MyPictures. While the Bukkit staff are all in their hole, thinking this new update has helped the community, and the community loves them for it, they're deluding themselves.

mbaxter, are you high? You do realize, that almost all of the remaining 1400 comments get across the same point as the first 100. Since you are not understanding, let me put it very clearly for you. They don't like the update.

So, this leads me to conclude that you think that the rest of the 1400 comments somehow proves your point. Let me ask you again, are you high? Please tell me, master mbaxter, how any of the 1400 comments show ANY change of mood from he first 100.

You go around and yell at people for not reading the main post or whatever. The problem with bukkit staff is, they read something clearly, and interpret it as the exact opposite.

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

MyPictures dreadiscool

I would encourage you to learn some basics of statistics. To quote a page from Stat Trek, a statistics education site:

The comments are not a valid representation of the community and cannot be used to adequately measure opinion.

dreadiscool, this is your last warning to drop the personal attacks in your replies.

MyPictures, as this thread and the commit thread and others have covered, no valid alternative was presented. Each suggested alternative was proven to not be viable. I suggest reading over the commit thread for EvilSeph's two giant posts on the matter. I think they're his second and third posts if you want to search down the page for them. The reason for not adding a field to bukkit.yml or plugin.yml is well covered by these posts.

Developers appear to have handled the change fairly well, with a few exceptions. Developers poking into the volatile and unsupported net.minecraft.server code are expected to be both skilled and adaptable as uncovering how the internals function requires skill and keeping up with internal changes requires adaptability. Every minecraft update, big or small, the developer of such a plugin should be checking over the changes, reviewing their code to make sure it still causes the same internal chain of events. All the package renaming commit has done is require that while doing this review, the developers update their code to the new package (after checking over as described) and build. Developers should have already been including version checks in their code (but they weren't) so this package rename provides version checking while also providing a handy way to write backwards compatibility (Checking package name, checking if your plugin has a class compiled for that package name, load the class). I provided an example (though now broken by NMS changes, highlighting the volatility of the code) here. I suggest a read, as it provides a great way to give your plugin multi-version compatibility with minimal effort. Takes me a couple minutes to update my plugins that touch net.minecraft.server classes, and the new compiled and uploaded plugin works with both the new and previous release of CraftBukkit.

This is not a major hardship on developers.

 

"Developers appear to have handled the change fairly well"
"This is not a major hardship on developers"

I would like to respond using a quote from TnT

Are there any statistics that you have gathered that show that developers are enjoying this change, and that this is not a major hardship on developers?

 

I can't comment on enjoying as I don't have access to the emotions of developers, but I can certainly comment on hardship. All this change has done is ensure that when checking compatibility in your plugin upon minecraft version change, which you should have already been doing every minecraft version increment, you also have to change package. Minor replace operation compared to all the work you should be doing each version to ensure your code still does what it used to. If that's hardship, maintaining your plugin already was a form of torture.

 

mbaxter I'm sure you will get bad reports if you ask the opinion of the NMS/OBC developers on this new SafeGuard. That's the only opinion that should count here if you ask me (who else will know this better then the NMS developers itself?).

I guess there haven't been made any pull request because the developers marked this commit as "not needed" anyways.
A NMS/OBC plugin can still crash the server without showing an error even if its updated to the latest CB/MC version.
This commit wasn't needed to have backwards compatibility in plugins, what this commit does is kinda FORCE having backwards compatibility for plugins now now (or your plugin wont work with older CB/MC versions).
Also for those NMS/OBC developers that have no idea how maven works or just don't want to use it at all (for whatever reason) will have big difficulty's to keep their plugins compatible now.

No one asked the developers to provide nay backwards compatibility at all, so I guess that's the reason why none of them saw the need to provide any of such compatibility? (Did you also have backwards compatibility for VanishNoPacket at the beginning and before this commit came in?).

You cant imagine how broken NC+ was after asofold "redesigned" it and how much time it took to find and fix all those new occurred bugs. We still have issues that we never had be before this SafeGuard.
Not sure about the other developers but for us it definitely made big problems to support this and on my opinion it didn't bring really any positives at all (at least for us). Lucky asofold had the idea to implement a automated "bukkitapionly" option, so if a unsupported CraftBukkit version is detected then NC+ wont use any NMS/OBC calls anymore and output a message that the user needs to update.

 

Speaking as a developer who regularly deals with NMS, and knowing many more who regularly deal with NMS, I can say that from my experience people are not bothered by it. Some were upset at first, but nearly everyone I've talked with has come around after discussing the benefits and teaching how simple it is to keep things updated.

Backwards compatibility ease of use is a side effect of the change, not the goal. If a developer can't figure out how to change their packages, they lack the necessary skill to maintain a plugin dealing with NMS.

Could you outline what major issues were caused by the package change? I don't see how the package change could cause any plugin bugs other than not working if the wrong version is installed.

 

What statistics do you have proving it is a major hardship? mbaxter is a developer that uses some CraftBukkit internals in his code, and is stating it isn't a hardship. Some developers that do use internals say its a hardship because they now have to update their code each Minecraft update (something we were shocked to learn they were not doing before, as those internals are volatile and prone to change). All you have provided is a he said/she said argument - circumstantial evidence based on your opinion.

Developers who have been responsibly updating their code each new Minecraft update have stated its not a hardship - because they already check over their code anyway, and a simple import is easy to modify if there are no changes. Developers using the Bukkit API, which are the vast majority (~90% of the plugins on dev.bukkit.org rely solely on the Bukkit API) are completely unaffected (these stats have been shown on the commit message). I have literally read every one of the 1600 messages - perhaps if you had read them you would be able to determine this yourself instead of asking to be spoon fed these stats.

We do understand this has upset some developers, it was bound to happen - it is impossible to force responsibility onto people without some of those people being upset. These same developers have been wreaking havoc on servers for 2 years before this commit - one only needs to look in Bukkit Help and leaky to see this for yourself - because they did not version their code. To help the community (Read this thread, you will find posts from people saying this has not affected them as drastically as claimed by those upset developers. The commit has similar messages.) we have taken the measure to force a version check. The results have been pretty noticeable. There has been no decrease in approved files/projects on BukkitDev (even a slight increase) and drastically less Bukkit Help requests and Leaky tickets generated. Its clear that the community at large has not been negatively impacted by this change, but has rather seen a positive impact.

 

We actually are still bothered by this SafeGuard but we try to be quiet and try to ignore the spam mails we always get on new MC releases (I hope BukkitAPIonly somehow makes this less annoying...).
We even have this written big in red: "

Since 1.4.5-R1.0 plugins that access CraftBukkit internals might break by default with new Minecraft updates. If you download from BukkitDev, be sure the file you download has your Minecraft version set in the "Game Version" section on the side. If not, you should ask the developers if the plugin version is compatible, test your plugins before going live, check your server log for errors!"​

And it still gets ignored.

Keeping plugins updated doesn't make anything more easy then it was before.

Yea but what exactly is/are the positive effect(s) of this SafeGuard? This SafeGuard doesn't really prevent servers from silently crashing (as I said before). A NMS/OBC plugin can still cause not unwanted issues/effects on the server without showing a log of any kind.

For big plugins like NC+, NoLagg and other ones, this "port to work with SafeGuard" might have caused some unwanted issues because of the "reformatting" of the huge amount of code. New plugins should have less problems to handle this new SG now (they just need experience with maven I guess).
Its not the package name change that caused problems, more the huge "reformatting" to make them work with the new SG.


However I kinda don't want to start such a discussion again. All that has to be said has been said on the commit already. I guess we just live with this new SafeGuard or drop the advanced plugin (NMS=Advanced for me) development and do something else in our freetime.

 

I'm a plugin developer who uses NMS calls in one of my plugins (ChessCraft) and while I won't claim I'm overjoyed by the safeguard, I understand why it was needed (and the radical changes coming up for 1.5 make it even more necessary). And, no, it isn't that hard to work with, even adding some backwards compatibility in (thanks for good example mbaxter). Any plugin developer who thinks it is too much of an effort shouldn't be touching NMS in the first place.

 

Most (if not all) NMS plugins will break and spam errors with Minecraft 1.5 anyways, with or without SafeGuard. The biggest problem was to make the big NMS plugins run with this. For example: NoLagg, NC+, ...

 

Right, and without the safeguard, some could break catastrophically (i.e. world corruption). With the safeguard, they just won't run.

 

I don't get all this hate. Do all of you who oppose this change not realize that the version number only changes when the entire net.minecraft.server package starts using a different naming scheme? That means that when the version number changes, all the function names will have changed too. If your plugins continued to work, they'd be calling the wrong functions. At very best, they'd "work" but with several bugs. At worst, you're looking at permanent map and player data damage, and frequent hangs and crashes.

Yes, it forces you to wait for inactive plugin devs to get their act together, but the alternative is you keep running that plugin, then it looks like it's working for the first day then trashes your entire map the next day.

If you don't know what code obfuscation is, then I suggest you trust the Bukkit developers who have a very intimate knowledge of it. If you don't understand it, leave it to the pros.

To reiterate one more time: The package name will only change when there is a very strong risk of non-updated plugins (even those with the highest quality code) crashing or causing data corruption. Where is the downside?

 

This is actually a good point where the SafeGuard would be useful but on the other side it will also break plugins that would have been worked fine for Minecraft 1.5.
Also how can you be sure that the author is going to update properly? He/she could also be in a rush and also forced to update due to the plugin users spamming and asking for an update. Developing on haste.... Woops error made.... Woops world got corrupt now...

Can you also cause world corruptions if you just use NMS to get information's? (For example block shapes)

 

If they would work fine, it will be a quick and painless update for developers. This has been covered by this thread and the commit message.

You're right. This is what would happen in that case: A server admin updates to a new Minecraft version. Plugins A, B and C break. They update plugin A, things work fine. They update plugin B, things work fine. They update plugin C and the world got corrupted. Now the server administrator knows to reach out to plugin C's developer for a fix.

Before this commit: No updates are needed, as the plugins continued to load, and continued to run. World corruption happens, but which of the plugins caused it? Now a hunt begins for these server admins to figure out which plugin broke their server. This is the best case scenario. If the world corruption is not obvious, a server could run for weeks with a corrupt world and their only recourse is to roll back weeks of work by their players, or reset the map. Having to do that can end a server.

This has been covered by this thread and the commit message.

Doubtful, but that wouldn't stop the need for an update when that NMS code changes. This has been covered by this thread and the commit message.

 

Yea but they could figure this out also before this commit came out or not? If you drop out all plugins and test all one by one you will find the corruption maker one also. Also only because A and B updated their NMS calls doesnt mean that they will work fine for a long time now. They can still cause world corruption without outputting a error log now and maybe it happens after a week or more, such errors are really hard to catch sometimes. All what this SafeGuard does is force the NMS plugins to use the right packet name, sadly that doesn't fix the fact that a NMS plugin could still cause corruption without throwing errors.

@Score_Under

Yea that's actually a point where this SafeGuard gets useful I agree with that but the problem is:
The way how it got implemented:

The Bukkit team implemented this SafeGuard way too unexpected and that was also the reason why everyone was so disappointed about it. It would have been better if someone (of the Bukkit team) would have made a post first and explained everyone what the plan and idea was but instead it just got kicked in a commit/development build and every developer was like: "WTF IS THIS?!" "WE HAVE TO LIVE WITH THIS!?". And after this commit the final RC with this SafeGuard came out and broke all plugins from 1.4.6 to 1.4.7. That wasn't nice and it made a lot of trouble for us at least (NoCheatPlus). "Triggering" the SafeGuard only on major Mincraft version is reasonable for me and I'm looking forward to this now and hope that it wont cause that much trouble as it did in the beginning.

 

The next time that something like isGrounded() gets renamed internally, I'd like to know

While I appreciate what the bukkit staff are doing, I don't agree with all of their methods, and there are many developers who don't either. But I guess we'll just have to deal with it. Please know, however, that in no way are the developers consenting to this change - we are just keeping quiet, as MyPictures and the hundreds of commentators on the commit have stated. It appears our input is not wanted here.

 

We always value input from users. That doesn't mean that we will always agree with each individual's requests or suggestions, but we are happy to respond to those. For instance, there were several suggestions of alternatives to this safeguard. We have responded (many times over) to each one.

 

As my statistics, I present the 1500 comments on the commit, and even the other people in this very thread saying that this was a bad update. So far, I have not seen the statistics that you claim to have

 

Please read http://forums.bukkit.org/threads/safeguard-versioning-policy.123435/page-4#post-1558407

 

It is biased for you to claim that you respond adequately to what the developers ask. It's akin to a king seizing all of his worker's possessions, and claiming that he is fair and just. Just as you may think that the statistics I bring up are biased, I feel that your statistics (referring tot he people that you claim agree with you) are biased as well.

I would like to reiterate, the staff claiming that the developers like this update and have come to enjoy it is not an adequate substitute for statistics.

I would like to see actual posts by other developers who are not staff.

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

I was referring to the statistics lesson at the top not my description at the bottom of the post.

Also, as for your request, here you go. http://forums.bukkit.org/threads/safeguard-versioning-policy.123435/page-4#post-1558625

 

I would like to bring the comments on this page to the stand.

Are you basing your entire statistical analysis on one person's post? It seems to me with this response that the staff haven't even prepared a statistical analysis until I asked them about it, whilst claiming to be backed by stats and facts.