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 dl.bukkit.org. 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 dl.bukkit.org, 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: Recommended: http://dl.bukkit.org/downloads/craftbukkit/feeds/latest-rb.rss Beta: http://dl.bukkit.org/downloads/craftbukkit/feeds/latest-beta.rss 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.