The Buildbot-0.8.x release series began in 2010. It represented an evolution from a small, single-hosted app capable of controlling a few workers to a partially-database-backed framework supporting large, complex use-cases. However, the model is not without its issues:
- Most data is not stored in the database, making it inefficient to access and difficult to reason about
- The web UI is almost entirely static, and implemented in a framework very few developers are capable of modifying. Many page views take multiple seconds to render, during which time no other processing occurs on the master.
- Interfaces and implementations are inconsistent and the documentation, while substantial, gives very little guidance as to what promises Buildbot makes and can be relied on from version to version. This makes updates treacherous.
- While multiple masters for load-balancing and resiliency are supported, this support is incomplete with lots of gotchas and corner cases.
Work to fix these and other issues evolved into a substantial project, Nine, to rebuild Buildbot on a better foundation and update it to support modern CI use-cases. This work initially took place in a project branch, which was created before the 0.8.7 release. That branch is now merged to master, and any changes based on Buildbot-0.8.x code will not be merged forward.
While there may be additional 0.8.x releases, they will be based on an branch that is no longer associated with mainline Buildbot development. Whether these releases occur, and whether feature development is allowed on the eight branch, is up to the maintainer of that branch, if one steps forward.
Work on eight is in the buildbot-0.8.x branch at https://github.com/buildbot/buildbot/tree/eight.
What This Means For You
It's time to think about transitioning to nine. We've worked hard to make this as easy as possible, although a great deal of functionality has changed or been replaced entirely, so the upgrade is unlikely to be simple.
Other options include:
- staying on your current Buildbot version
- upgrading to 0.8.9 and staying there
- following each release on the 0.8.x series, but never jumping to nine
All of these have clear drawbacks, but may be more appropriate for your organization.
Basically, if you're not hacking on nine, you're writing already-deprecated code that will not be merged to master.