Beyond CraftBukkit 1.1-R4

Discussion in 'Bukkit News' started by EvilSeph, Feb 16, 2012.

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


    As you're now all aware, the past month has been an extremely busy one for Bukkit. Not only were we working tirelessly to get a new Recommended Build out, we were also busy getting ready to launch our new download site With these two things out of the way, we are now one big step closer to providing a better service to the Minecraft community through our project.

    Our reasoning behind getting a new Recommended Build out was to bring our server admins that rely on or are locked into our Recommended Builds the latest changes, additions and critical fixes to Bukkit. While the launching of our new download site provides us with the necessary tools to move over to a new, improved release model. One that we feel will better serve the community and give server admins of various levels of skill and dedication the freedom they're looking for when it comes to maintaining their server.

    A New Release Model
    As the Bukkit Team Lead, I have to often make tough decisions that many people might not always agree with. When it comes to getting a Recommended Build out, for example, there is a delicate dance to go through to figure out when is too soon, too late, too often or not often enough. Whenever a Minecraft update comes out, I need to decide when the time is right to get a Recommended Build out: too early and it could be unstable and cause irreparable damage or we'll need to get a new RB out shortly after to provide new features and API; too late and people start to get impatient that we don't have an update out yet.

    Usually, we'd point towards the fact that we're an open-source project with development builds made ready as we push code live but people or companies have taken to locking themselves or their customers into our Recommended Build system, and so may not have the freedom to use one of our development builds. While we know that we can't please everyone, that won't stop us from trying our best anyway.

    With the release of, we can now be significantly more flexible with getting releases out to the public without making things too complicated. While we will continue to push people to use Recommended Builds over any other, DLB allows us to provide different levels of releases effortlessly and intuitively for the more advanced server admins out there to take advantage of while still maintaining the usefulness of a Recommended Build.

    The new release model:
    Next -> Development -> Beta -> Recommended

    Recommended Builds: these builds go through extensive testing, overview and are what we recommend most people use. A Recommended Build will be promoted every two weeks or so as we deem builds stable, non-volatile and API complete.

    Recommended Example: when a new Minecraft update comes out, a Recommended Build will be promoted only when we deem a build stable, non-volatile and API complete.

    Beta Builds: these builds simply work and are promoted much more frequently than a Recommended Build. While we will do some testing before promoting a beta build, we will not be running it through our extensive test process. As such, there are no guarantees that they will not contain minor bugs. If we do find out they are broken, we will mark it as such on DLB and it. A beta build may contain incomplete API and new features but they should not interfere with running the build in any way.

    Beta Example: when a new Minecraft update comes out, we'll promote a beta build once we have one ready that is compatible with the update, compiles and has been lightly tested. This is so those of you that want to update to the latest Minecraft update can do so while those of you who want to wait for a feature-filled, tested build can wait for a Recommended Build.

    Development Builds: these builds are made available as we push code live. As a result, we do not guarantee that these builds are stable or will even run and do not support them in any way, shape or form. These builds are primarily made available for developers and should never be ran on a production server unless you know what you are doing.

    Next Builds: these builds are EXTREMELY experimental and running code that has not undergone any review. These builds are made available to advanced server admins who want to help Bukkit test new, experimental features, changes or fixes and should NEVER be ran on a production server.

    We hope that people and companies who have come to rely on our Recommended Builds system will move over to this new one as we will be switching to this new release model with the release of Minecraft 1.2. DLB was designed from the ground up to provide us with the features necessary to make your adapting to our new system painless and largely effortless. Take a look at our DLB API or use our RSS feeds:


    If you're having difficulty, please post a reply to this announcement and we'll try and help you out.

    Update notifications
    With this new release model, the need for an update notification has become more apparent. With so many different types of builds, it can be hard to keep track of when an update comes out for the type you're interested in. Well, no more! We're working on an update notification system built right into Bukkit that will let you know whenever an update is available for the kind of build you're running on your server. We'll never force an update on you, but now you'll be notified right away when one becomes available so that you can decide when the right time to update your server is for you. If you choose not to use the system, you'll be able to turn it off whenever you want.

    Improving Bukkit
    As the project grows, our code changes and improves. Old, inefficient code is deprecated to be replaced by better code. Poor design is weeded out to make way for better design. We're not afraid to make mistakes and admit we're wrong, as doing so means we can provide a better product for the Minecraft community. Unfortunately, as times goes on, we need to make the difficult decision of cleaning out unused or bad code in order to produce a better product. If we continue to add new things while keeping old, broken and inefficient code we won't be able to grow, innovate and improve.

    That being said, we are planning to remove all deprecated (read: old) code in a new Recommended Build, R5, soon before Minecraft 1.2 hits so that we have a cleaner code base to work with when the update comes out. This means that old or misbehaving plugins will break and need to be updated, but it will be for the better as it helps Bukkit improve.

    Bukkit Announcements
    A while back I started up a Bukkit Announcements mailing list that has primarily been used to notify subscribers whenever a new Recommended Build came out. Recently, it was brought to my attention that there is a security issue with a certain plugin and it prompted the discussion of setting up a security advisory mailing list. As such, I would like to ask the community what their thoughts are on either starting up a security advisory mailing list or making use of the Bukkit Announcements mailing list for more than Recommended Build notifications.

    With this change, we'd be sending out a bulletin whenever we got wind of a security issue in a plugin or Minecraft itself to help keep server admins on their toes. The downside is that there is no proper way for us to ensure that people subscribing won't use the information we send out for malicious purposes. What do you guys think?

    As always, thanks for your continued support. We hope that these changes we are making will help us better provide you with what you're looking for in a Minecraft server management and customisability solution.
  2. Offline


    Good job guys! Keep it up :D
  3. Offline


    I like the change. I think I'm a beta baby! >.>

    I think I agree with this too. I say put out a patch ASAP, then notify. Try hard to get all operators on that list (to not do so is to risk your server), maybe with a headline on the top of the forum/dbo.

    I would also like the ability for plugin devs to get security issues pushed there. There was quite a bad issue with LWC this past week and there will likely be vulnerable servers out there for months.
    Don Redhorse likes this.
  4. Offline


    The changes are great....
    I'm running a small server for a few people which I know personally. My users want new updates as fast was possible but it was very hard to decide at which point a dev-build is ready for daily use. The new beta-channel is perfect for me.

    About the mailing-list: Where can I register for the announcement mailing list?
    The security mailing list is also a good idea but for me it doesn't eally matter if it is a sepereate list or not.
  5. Offline


    I suppose with all the other ways to get bukkit info, the mailing list seems... outdated. But I use that at the moment, so +1 for security updates through that from me!
  6. Offline


    Yeah, because that never happens. :p

    As for the Bukkit Announcements, It's a good idea - but I agree that it should be done via RSS feeds instead of a mailing list (and there's plenty of sites that allow you to get emails from new RSS feed items if you do want emails).
  7. Offline


    Please do. I think this is a great idea.
  8. Offline


    Ugh. You've used AuthorNagException before, you should have at the very least had an RB where out of date plugins would throw an error if they implement and use deprecated functions. Instead you're taking the route where admins are going to have no idea if their plugins need updating or if they're going to be okay.

    Plugin devs can handle the change no problem, but your users are going to be confused. Heck, they're already confused. Go read the Plugin Releases forum and see the list of posts of users wondering if their insert-favorite-plugin will be okay for the next release.

    I seriously hope you reconsider and push this back, and do it right.

    +1 since this needed to happen, -2 for execution.
  9. Offline

    Wolvereness Bukkit Team Member

    Supporting the old system is a lot of work, in addition to inefficient. Pushing it back would simply delay any further progress on bukkit, especially adding new API for 1.2.
    Admins should be updating their plugins anyway as each recommending build goes out, or at the very least looking at the change logs for bugs and exploits. Plugins that have been updated to 1.1-R1 or later would have seen the deprecated messages and been able to update.

    As far as your "-2 for execution", at what point should deprecated code get removed? Between now and X time in the future, it'd just waste a proportional amount of development time supporting two systems, in addition to putting more strain on servers (because cycles aren't free). How much more clear could this be?
    samp20 likes this.
  10. Offline

    Don Redhorse

    well.. honestly... build 1818 R1 which "forced" the new event system upon us was released: Jan. 25, 2012, 9:32 a.m. The first real RB without any issues (1846 R3) was even pushed out Jan. 30, 2012, 8:46 a.m.

    That is approx 1 month in which the deprecated OLD event system is removed, and this will break ALL plugins which still use it.

    The announcement that there is this quick change to remove THOSE deprecated events is even younger.

    This is a MAJOR breaking API change, and while I DO understand the reasoning behind it I can't understand why this wasn't announced earlier or given more time.

    And I agree that warning the admin just per se wasn't the best approach either.. the AuthorNagException would have been far better as that would have shown every admin directly which plugin still needs updating.. at least in the important areas of events and configs.

    So atm I'm updating all my plugins and put a message out there that they are R5 ready.. and hope that everybody is already on at least R1 because the plugins will not work with older builds anymore.
    Celeo likes this.
  11. Offline


    +1 to deprecating new event system. As a semi-active Bukkit Help member I'm ready. :)
    +1 to Sleaker saying we just get rid of plugin submissions on the forums
    +1 to security updates via email and/or RSS feeds

    I can't wait for the chaos.
  12. Offline


    Offtopic posts have been cleaned up. Please stay on topic moving forward as we can't have important information or discussion pertaining to this announcement being buried under any occurring thread derailment.
  13. Offline


    what you talking about? the forums are in chaos 24/7!

    anyways EvilSeph any idea when this new 1.2 build will be thrown at us?
  14. Offline


    Whats up with the 404? Can't download R4.
  15. Offline


    Just keep your computer running...
  16. i got question: is there bukkit for 1.2 minecraft pre-release? any kind of bukkit version ? :O
  17. Offline


    No. Bukkit only updates for releases, not snapshots.
  18. its kind a stupid coz id wanted to make 1.2 with bukkit already..
  19. Offline


    I'm pretty sure you'd rather have the team improve the current code then trying to constantly compile a new CB for every snapshot that comes out.

    Making CraftBukkit work for each snapshot would take up too much time to allow the team to effectively improve the system.
    Don Redhorse likes this.
  20. You go through the hassle of performing a bukkit update, and then your views will change on that.
    billofbong likes this.
  21. Offline


  22. Offline


    R5 was just released. Thanks for the work, Bukkit staff!
  23. Offline


    When does the 1.2 Come;D
  24. Offline



  25. What he said. This is really annoying for us server owners and should have been handled better.
    Don Redhorse likes this.
  26. Offline


    nice but i think alot of people are like "how do i run my craft bukkit server now?" even i was thinking that i hav school m8 that plays it with me
Thread Status:
Not open for further replies.

Share This Page