CraftBukkit 1.5.2-R1.0 RB CANDIDATE is now available!

Discussion in 'Bukkit News' started by EvilSeph, Jun 13, 2013.

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

    EvilSeph Retired Staff

    A Recommended Build candidate with Minecraft 1.5.2 support is now available!

    What's an RB Candidate?
    A Recommended Build candidate is a build of CraftBukkit we designate as having an extremely high chance of becoming our next Recommended Build release. These candidates are released to help facilitate and direct testing efforts within the community to ensure that we are, indeed, ready to release it. As many servers rely on our Recommended Build system to run their servers with the peace of mind that their production servers will run without any problems, we like to focus the efforts of our community on testing our candidates to make sure that there are no glaring bugs present.

    If there are no issues discovered with this RB Candidate, we'll likely be promoting this build to a proper Recommended Build soon afterwards.

    Why did this RB take so long?
    Many servers within the Minecraft community have grown to trust our Recommended Builds system as a sure fire way to run a stable and problem free Minecraft server. Unfortunately this trust means that we can end up having delays on our path towards the next Recommended Build as we strive to provide the highest quality product we possibly can.

    Simply put: we were unable to promote a build until we had proper support for the new features added in recent Minecraft updates or else we'd run the risk of leaving servers in a situation where they would not be able to protect themselves by controlling each feature if they found a need to. One major delay we faced with this Recommended Build was needing to design and implement new API to support plugins that need to manipulate and control the new inventory related features like, for example, double clicking and drag clicking within the inventory.

    Realising the need for this feature to be completed, I placed the project under a code freeze and directed all project resources to moving us towards a Recommended Build. Though this did result in a quiet period for the project where we saw little to no activity on the development side, the code freeze did help bring us forward towards this Recommended Build candidate as we put our collective heads together to tackle the problems we were facing.

    The unfortunate truth is that Bukkit is built on an unpredictable moving target that the project has no control over. This unpredictable and fluid nature is also the reason why we do not and simply cannot provide the community with any ETAs.

    How do we plan to prevent further delays?
    We are planning to make big and exciting changes to the Bukkit project. Some of which include rethinking the way our project is organised and functions by, for example, splitting our development teams into three separate areas:
    - Update Team: responsible for updating Bukkit to support new Minecraft updates, as well as moving us towards the first Beta and Recommended Builds following a Minecraft update.
    - Development Team: responsible for day-to-day development of Bukkit and design decisions, working closely with the Pull Request Handling team.
    - Pull Request Handling Team: already established, responsible for handling, responding to pull requests and getting them handled in a timely manner.

    Naturally, this new team structure means we're planning to expand and grow our numbers as a project and will be opening up the project with a new application process among other things.

    The idea behind this change is that we will no longer have 3-4 individuals responsible for every aspect of development within the project. Instead we will have specialised groups that are clearly responsible for certain aspects of the project, reducing the amount of stress and burnout our team members experience as a result of Minecraft updates, API work and so on. I'll be going into more detail about these changes in future announcements but our Pull Request Handling Initiative was simply just the beginning.

    Download and help us test the CraftBukkit 1.5.2-R1.0 RB CANDIDATE here
     
    tanveergt5, jorisk322, TnT and 9 others like this.
  2. Offline

    YoFuzzy3

    Haha Twitter has spoken. :p
     
  3. Offline

    np98765

    Nice work team! I'm glad to hear that there are some organizational improvements so just a couple devs aren't being tortured :p
     
    hawkfalcon, jorisk322 and drtshock like this.
  4. Offline

    MinecraftMP

    Will there be a new color code for RB candidate on http://dl.bukkit.org as it still appear as a "Development build"?
     
  5. Offline

    TnT Retired Staff

    Great work team.

    Please use Bukkit Help for assistance. Posts looking for help in this thread will be removed.
     
  6. Offline

    -_Husky_-

    Always nice to see changes, good job guys.
     
  7. Offline

    tumbleshack

    Thanks guys!
     
  8. Offline

    ASHninja1997

    Awesome work. Can't wait for more :D
     
  9. Offline

    creepers84

    Fantastic =D Thanks for getting it out!
     
  10. Offline

    Herogx

    My only question is; why weren't applications/whatever opened up sooner? I'm sure there are hundreds of people who would absolutely love to take part in the bukkit project. :)
     
  11. Offline

    Onionbro

  12. Offline

    dup9let

    Very Nice!
     
  13. Offline

    Hoolean Retired Staff

    Excellent! Well done guys :)
     
  14. Offline

    jorisk322

    Great work. Love the new team-layout.
     
  15. Offline

    Ultra1108

    I would like if there was a build where you could do /disable <plugin name> to disable a plugin, and /enable <plugin name> to re-enable it. Please reply and tell me if you can do that. - Your friend, ultra
     
  16. Offline

    vgmddg

    I think that would require a lot of work to implement directly by the Bukkit staff. It would also cause issues with plugins that depend on other plugins to function, much less the plugin itself.

    Perhaps some alternatives would be for the plugin developer to add in the ability to disable their plugin and cause it to "hibernate", or to make a plugin library that would create an API for other plugins to do this.
     
  17. Offline

    nxtguy

    Awesome job guys! (Like always. :p)
     
  18. Offline

    Bobcat00

    Build is running fine.
     
  19. Offline

    kin61

    cool!
     
  20. Offline

    TnT Retired Staff

Thread Status:
Not open for further replies.

Share This Page