The Status of Bukkit

Our Release System
The most common complaints we've gotten about our new release system is that getting a Recommended Build out is taking considerably longer than before. The reason we switched to a new release system is because the amount of work that we have to do to get a Recommended Build out meant that there was a huge delay before servers could update and this was unacceptable. We felt that you should be able to choose if you wanted to take a risk and run an update immediately or shortly after Mojang released it or to wait for us to certify and release a Recommended Build.

For the most part, our new Beta releases are what our old Recommended Builds were. If you can't wait for us to go through the extensive testing process we've designed to certify a Recommended Build, then you should be using the Betas. We know that many of you want us to promote a Recommended Build shortly after a Minecraft update is made available, but expecting as such is unrealistic. It is simply not possible for us to go through the 190+ tests, design and develop new features and fix all the bugs within a week, let alone a few hours or days. If we were to promote a Recommended Build shortly after an update came out, there is no way we could seriously consider it "recommended" and it would only prove to be misleading to the Server Admins out there that rely on our Recommended Builds system to determine if a build is stable enough to be run on their production servers without the risk of their world being corrupted or something.

As a result, we designed and switched over to a new system that offers Development builds to Server Admins that love being on the edge, Beta builds for Server Admins that simply want something that is stable enough for production and Recommended Builds for those who want to be completely assured that we've addressed any major issues that have come up since the Minecraft update was released.

We feel that this system offers us the freedom to cater to the many different types of Server Admins we have in our community and will continue to follow this release model well into the future.

The Future of Bukkit
Over the past few months we've been working closely with the community as part of the Bukkit Bleeding system on the development of Bukkit. The speed and quality of the code within the project has been significantly improved by the skilled, dedicated and passionate individuals of the Bukkit Bleeding team and many of the features in Bukkit today would not be there if it were not for them. This group of developers were integral in allowing us to properly utilise and realise the potential of the new dev -> beta -> RB release system we recently switched to, as well as helping us get builds out faster without having to sacrifice quality or stability.

That being said, it only makes sense that we bring in some of the contributors from Bukkit Bleeding into the Bukkit Team itself to help us maintain the project in our absence as we intend to focus on designing, developing and releasing a high quality modding API for Minecraft itself. Without further ado, I'm really happy and honoured to announce that, effective immediately, feildmaster and Wolvereness are now a part of the Bukkit Team. Please join me in welcoming them to the team, with the amount of work they've been putting into the project behind the scenes, they more than deserve it.

We hope that the changes we've made and continue to make will be for the best for the community and the project and thank you for your continued support. Along with the new additions to our team, we're hoping to have a Recommended Build ready for Minecraft 1.2.5 right as Mojang releases it to the public. Thanks to Mojang releasing a preview build for modders to work with ahead of time and this update primarily being a bug fix release, we should be able to have a compatible, stable build available at the same time the Minecraft update is pushed out to the public.

I actually don't mind the new release system, I'm patient. We actually stayed on 1.1-R4 for approx. 2 Weeks after the 1.2 release, but afterwards we've tested the dev and beta builds on a 'TempMap'; while we patiently waited for a 1.2 RB and now we're there we're currently in the process copying stuff from a 1.1 Map (Converted to 1.2.4 Dev; successfully) to a new map to support the new world generation. (Mainly Jungles)

I haven't talked too feildmaster and Wolvereness as of yet, but I'm usually in IRC and hope to get to know you and welcome to the Bukkit Team!

If it is so that i am a plugin coder, when I go to the www.ci.bukkit.org where i can download the snapshot file (I have read that) I just get that i should read permissions and i dont know what i should do to continue coding?! Please help me!

If it is so that i am a plugin coder, when I go to the www.ci.bukkit.org where i can download the snapshot file (I have read that) I just get that i should read permissions and i dont know what i should do to continue coding?! Please help me!

I think it is fantastic what work has been done to try streamline the update process, but I still think there needs to be some way the latest client will connect to older servers. At the very minimum the last release e.g. a 1.2.4 client can connect to a 1.2.3 server and a 1.2.3 client can connect to a 1.1 server. As Evilsteph says:

Whether or not Mojang notifies the Bukkit Project ahead of time makes little difference. The frequency of our updates is unpredictable as the complexity of Minecraft updates varies each time. The delay is purely on our end as we need to go through an extensive process to update Bukkit and ensure that it is stable enough to be considered 'recommended' before I am happy with releasing something.

Click to expand...

Bottom line there will always be a delay in these things with very good reason... but with the current Client update system it causes interruption and adds complexity for people who are not server admins and simply just want to play the game on their favorite server.

There were some great suggestions made in http://forums.bukkit.org/threads/minecraft-1-2-4-is-out.66599/ sadly buried in the 800+ comments. I spent ages reading all those trying to find anyone thinking along the lines above. I suggested a Bukkit client but sadly I was shot down with that idea with valid points. That said I think something needs to happen for a complete seamless experience for the end user who just wants to enjoy the game with no fuss.

While this is all well and good, reasonable in fact and even tho IMO it was abundantly clear the first time you announced the release changes while other people around here choose to ignore that is not your problem but I thank you for the extra info.

ButThe issue still remains that even after SUCH a long wait for the recommended build we still find annoying bugs and changes in it that while are not related to stability but effect not often used or useful events that either get blindly stripped out for no apparent reason and then re added a build later such as that stunt pulled on the vanilla client that now renders editing sign text with a sign useless as the client no longer sends the packets do not get sent so you cannot read what the hell you are editing anymore.

Or are directly related to Bukkit and not vanilla such as some of the issues with the previous 1.2.3R1 that got effected events used by plugin devs that made there way back in 1.2.3R2.

That is the issue a lot of us have with the system not the fact that there is Beta's or a long wait for the RB, most us just want to see consistency about decisions made in relation to changes and not just doing random things that remove ability to use it creatively that happen with no reason as to why it was so bad it got removed but more importantly if your going to make a change and them promote the build don't take the change back in the next build.

Constancy is about thinking more about what you change and how it will effect the community then acting on it, we don't want to see this kind of thinking (Hmm that event needs work lets remove it, oops that was bad lets put that back in asap.)

I point the finger at you guys for the Vanilla Client change that leads to signs not being editable anymore with out a command because it was clearly stated that you guys made that change. What was the reason for that ?

We never got one and it makes no sense as to why you would stop the text packets as that was damn useful for modding.

That is my 2cents worth on this new system others might feel similar to this.

Don't take it personally Your team are no1 imo, sure you got some kinks to keep working out just remember how this started out before you sell out that's all I'm saying.

...Or are directly related to Bukkit and not vanilla such as some of the issues with the previous 1.2.3R1 that got effected events used by plugin devs that made there way back in 1.2.3R2....

Click to expand...

You lost me on 1.2.3R1 and 1.2.3R2, considering there was never a recommended build for 1.2.3 at all. 1.2.3 was broken, there were bugs that had to be fixed client-side as well as vanilla-server side. So... You need to provide context instead of speaking in broad generalities.

While this is all well and good, reasonable in fact and even tho IMO it was abundantly clear the first time you announced the release changes while other people around here choose to ignore that is not your problem but I thank you for the extra info.

ButThe issue still remains that even after SUCH a long wait for the recommended build we still find annoying bugs and changes in it that while are not related to stability but effect not often used or useful events that either get blindly stripped out for no apparent reason and then re added a build later such as that stunt pulled on the vanilla client that now renders editing sign text with a sign useless as the client no longer sends the packets do not get sent so you cannot read what the hell you are editing anymore.

Or are directly related to Bukkit and not vanilla such as some of the issues with the previous 1.2.3R1 that got effected events used by plugin devs that made there way back in 1.2.3R2.

That is the issue a lot of us have with the system not the fact that there is Beta's or a long wait for the RB, most us just want to see consistency about decisions made in relation to changes and not just doing random things that remove ability to use it creatively that happen with no reason as to why it was so bad it got removed but more importantly if your going to make a change and them promote the build don't take the change back in the next build.

Constancy is about thinking more about what you change and how it will effect the community then acting on it, we don't want to see this kind of thinking (Hmm that event needs work lets remove it, oops that was bad lets put that back in asap.)

I point the finger at you guys for the Vanilla Client change that leads to signs not being editable anymore with out a command because it was clearly stated that you guys made that change. What was the reason for that ?

We never got one and it makes no sense as to why you would stop the text packets as that was damn useful for modding.

That is my 2cents worth on this new system others might feel similar to this.

Don't take it personally Your team are no1 imo, sure you got some kinks to keep working out just remember how this started out before you sell out that's all I'm saying.

Click to expand...

With all due respect, I can't understand a word you're saying. Can you slow down, think things through and rewrite your post please? We value feedback but there isn't anything we can do if we can't put your feedback together into coherent points. Nonetheless, I'm going to try and take a stab at addressing what I can make out.

By the way, did I mention things are going to change between Betas? Yep, I did. That's why they're Betas and this isn't going to change. If you want stability and consistency, wait for an RB. That's what this new system is for. I think part of the problem here is that you don't understand the difference between R0.1 and R1.0. We never had ANY R1 or R2 for 1.2.3 and yet you've stated we have. If we HAD gotten 1.2.3-R1 out, then changed our minds about whatever was in it and then gotten 1.2.3-R2 out, I would agree with you. But since this isn't the case and we were only working with Beta builds, I don't see an issue.

Dev builds are fluid and will have experimental changes in them that we may or may not like. Betas are a small step up from Dev builds and are also fluid, though not as fluid as Dev builds. The only consistent and constant release cycle is the Recommended Build release cycle and since what you described is exactly what it has to offer, it is clear that you should be sticking to Recommended Buids.

This is how we're choosing to do things. It gives us the most freedom to cater to the different types of Server Admins while not stifling improvements and innovation, and so, is how we'll most likely continue to do things for the foreseeable future.

im so happy to hear that a 1.2.5 RB is coming out right away
the server that i am on was dreading this update, saying updates were going too fast, and that by the time bukkit updates 1.2.6/1.3 will be out
I will be happy to prove them wrong, and tell them that the RB is coming out right when we can force update

When I first saw the news that the Bukkit team had joined with Mojang, I thought what would happen was exactly that. I'm fine with the build process that is currently in place, but it would make sense if both teams just meshed together and developed and released one server jar together.

EvilSeph, Being one of the more vocal voices during the 1.2.3 -> 1.2.4 crisis, I want to say thank you for the new update scheme! And, thanks to Mojang for making this happen too. I was able to grab the 1.2.5 pre-release of the Minecraft client and the latest dev snapshot of 1.2.5 bukkit and test my plugin against it on my server. Everything is working correctly and my plugin will be ready for when 1.2.5 comes out. Thanks again! This is great!

Sorry, I did not mean to sound rude or anything, I respect you guys a whole bunch.

I do understand why we have beta and RB I thought we did have 1.2.3 RB I did not know this is my mistake, but my overall point was not really about RB and BETA consistency I get that there is a reason why they are BETA.

It was about the consistency of the teams decisions to either keep something or not keep something, like I heard and I agree with developers who used certain events that later get stripped without a reason as too why it was removed, then later re added this type of thing is an annoyance to developers who need to go adjust their code for these silly changes but then turn around and re add the old code back when the event returns.

I gave an example of something that I don't personally like that has changed.

This was done to vanilla client, how it does not send the text packet anymore when editing a sign, before 1.2.4 it was possible to click a sign with an item like a sign and display the sign your editing's text on the new sign so you could visually see the edit. Then send that back to the sign you clicked and it would update upon pressing enter, basically it was if you made a new sign but instead you just edited the one you clicked.

This is not the case anymore now the text on the sign u click does not appear on the new sign to edit, you can still edit it but you cannot see what it is your typing. This was caused by removal of some packet that used to be sent to client but no longer is. I liked it how it was before now I have to use command based sign editing which I never did like .

I am sorry I cannot explain/express things properly in a way you can understand better. I never was any good at explanations but what I am trying to get at is that sometimes an RB came out and it had an event removed this event was then re introduced the following RB because people did not like it was gone.

I just feel that maybe the people who develop deserve more of a say about what events should remain and have a better and easier time expressing these concerns to your team and the team will listen to the ideas. A lot of real talent around here in the past have made pulls that have been denied or ignored for what ever reason but I have seen some excellent ideas go unnoticed in the past that improve both stability and performance.

If you need me to break it down into key-points I will try and do this.

More feedback is needed before making the choice if something should be scrapped from the event system instead of later taking the change back for what ever reason. People have a opinions not giving us the option to express them kind of defeats the community aspect.

Too many great ideas go unnoticed or are just flat out denied without any word such as to why your team decided to not implement the feature or pull request, I understand your team are working on a system that is supposed to make this side of things better but still it would be a shame if we did not get a reason for the denial I would agree that moderation be taken to reply only to the popular ideas with good user vote up that is logical.

Why was the packet events removed from the vanilla client that allowed us to edit a sign and visually see the edits in real time when using another sign to edit with?, Mojang posted that it was thanks to some Bukkit team members for certain features in last update I know that this edit was one of them. I like a couple others are just lost as to why this was done, what gain did you get from doing it ?

Edit I was incorrect about the sign thing and who did this sorry, wish it was fixed though.

My end point on my first post was just to let you guys know that the community does care and that we just don't want to feel like we are in the dark about things, not myself personally but many other fine developers have helped this project rise to its glory that it is today. I don't want this merge with Mojang to ruin the connection we already have as that is getting harder to grasp the more ideas get pushed back. That being said the announcements and communication is getting a lot better .

I don't understand why we need another post explaining the changes of BETA and RB, it was already announced people should take note or keep waiting, you guys have more important things to do then remind the ignorant.

Anyway thanks for your time.

Oh before I forget, The TnT crash bug that's was supposedly fixed was only half fixed. There is another way to crash server with TnT I think that was not addressed so the bug was only half fixed I will explain the other way.

Wire all the TnT into a Wire of redstone.

Stretch the wire till the chunks with TnT are unloaded.

Activate the redstone wire.

Go back to the TnT so the Chunks reload, the redstone activates all the TnT at once.

Depending on how the bug was fixed the above method may crash the server still. I don't know if your going to look into this matter but I was just going to throw it out into open.

bergerkiller knows about them I only heard about them from developers and by reading the change logs, I don't recall these things myself in detail as I do not actually code, but I do read when others vent about it.

You lost me on 1.2.3R1 and 1.2.3R2, considering there was never a recommended build for 1.2.3 at all. 1.2.3 was broken, there were bugs that had to be fixed client-side as well as vanilla-server side. So... You need to provide context instead of speaking in broad generalities.

Click to expand...

I see I must of gotten confused, I admit that I am wrong on that account then. My feedback for this would be to instead not even put an R in it instead put a B like B0.1.

Also in this case I think the BETA download section needs to be more clear as the Bukkit RB download page only shows RB on the download and prior to now it was showing 1.1RB and not many people notice that it has alternative versions. So EvilSeph that is some more feedback for you .

ledhead900 The sign edit packet error is caused by the Mojang team, as this bug is in the Minecraft client. You will probably have to confront them instead. (I looked at CB's source, they didn't do anything like it)

Event consistency...the complete story

Level one: deprecation
The regular event system got deprecated (with listeners). A new system was introduced using @EventHandler tags.

Level two: removal
The old system was completely removed. All plugins using it (prior to november or so) would break.

Level three: custom event changes
The constructor to set the event name got removed. All plugins supplying custom events (Minecart Mania is one of them) broke.

Level four: rapidly changing event declarations
The 'damage vehicle event' and 'block break event' constructor got changed; adding a list of itemstacks for droppings. BUT YOU DID NOT KEEP THE EMPTY CONSTRUCTOR. This caused all plugins that generate this event (SignLink, TrainCarts in my case) to fail. I fixed it. A few days later, you undid this change...had to re-publish it all AGAIN.

Level ??
Let me guess, you will add the droppings again? Seriously, the inconsistency here is tiresome to say the least. Tell us what you will do with events so we can at least prepare for a new system...

Build consistency....the complete story

Level one: the lazy life
Build 1060 was the best build ever. It was consistent for over 4 months and everyone was happy with it. It was able to do what it had to do and had zero bugs.

Level three: chaos
1337, a later build, gave me some hope too. But, close but no cigar, the 14** builds came into existence....

5 updates in one month? This is ridiculous! I keep on updating my plugins and people KEEP ON requesting new versions while the old one still works! Give us a recommended build for a few months and that would be GREAT.

Level four: iQuit
This is just not doable for someone that develops in their spare time. The day after I publish a new version for 1.2.3 MC 1.2.4 comes out. I mean...really? This is just not doable. I will just update at very low intervals and check if it is doable to update...

I understand that some of these issues are Mojangs fault, but couldn't you, by now, gotten some persistence in your project? Even having a consistent event system has failed...

Obfuscation is the major issue, as I don't see why you have to copy-paste the Minecraft server source code into your project all the time. Look at what got changed and keep the function names...seriously.

My major rage here is with the builds change. I now have to support your beta builds too?!