Blender Release Cycle

Blender has officially entered the Blender 2.81 bcon2 phase. To understand what that means let’s step a little back first.

Blender 2.80

The Blender 2.80 release was really well received, and gave solid powerful new features to the entire community. The scope of the project and our development strategy, however, lead the project to stretch for a few years. On one hand there were features pouring in master continuously throughout the years, while on the other hand there were months entirely dedicated to bug fixing and fine tune polishing alone.

But how did the community react to that? What happens when the Blender developers keep a production-safe release “held hostage” until a final glorious 2.80 release? Well, the community spends the waiting years downloading, building, testing, providing feedback, and – surprise – using it for high profile events worldwide.

EMMYS 2018 Motion Graphics in Blender
EMMYS 2018 Motion Graphics – by Allucinari, made with Blender 2.80 alpha

Were there bugs in the beta versions of Blender? Sure thing. Were there known issues in the final released 2.80? Unfortunately, yes. And yet the community was using it everywhere. Bugs aside, there were also numerous patches that were neglected.

And now it enters the new release cycle structure.

Blender 2.8x

For the 2.8x series the Blender project is back to a more strict cycle where bug fixing and new features sprints alternate back and forth:

  • Bcon1 (9 weeks) starts with developers committing approved patches, or sending them for review. This is when time is allocated to assist collaborators with their work, and when the community and developers have an initial picture of what likely will be in the upcoming Blender.
  • Bcon2 (4 weeks) is fully dedicated to bug triaging, fixing the high priority bugs and stabilizing the recently merged features. Thanks to the limited scope of what is merged in bcon1 the developers can really focus on delivering well polished features, while the remaining can get improved in time for the next bcon1.
  • Bcon3 (4 weeks) is when things get really interesting. At the same time of the bcon3 for the current Blender release, the bcon1 for the next release starts. A new release-branch is created to leave master open for new features, while Blender project coordinators assess per-module whether the developers should work on new features or if there are high enough issues that still need attention.
  • Bcon4 (1 week) is a phase where only critical commits are merged, and the community can test what will become the shipped new stable Blender release.
  • Bcon5 (1-2 days) is a stage where final builds are packaged for all platforms, final tweaks to the logs and promo images, social media, video announcements, and the final switch is flicked on blender.org for the new release to show up in the Download page. Time to make some noise!

Full disclaimer, as with anything in Blender’s dynamic structure, this may change in the future, sanctioned by a developer meeting.

Blender 2.81

As mentioned before, Blender is already in bcon2, meaning that the developers have settled on what is expected to be part of Blender 2.81. From its release notes we can already glance at what is coming soon:

But don’t get too attached to these just yet. If by the end of bcon3 (or even bcon2) the blender project coordinators sense some features may still be in a rough shape, they may still pull it out of the release.

Meanwhile give the nightly builds a go and feel free to join the development efforts on finding and fixing any bugs that may be in the way.

17 comments 19,704 Views
  1. I honestly think these releases are too far apart. Especially when some components of the next release are stable and working already. A constant drip update would be better than big bucket full updates every few months. It would give users quicker access to new features and it would mean developers wouldn’t have to dedicate a big release cycle to bug fixes. They can just focus on bug fixing small components and releasing them when they’re ready, old version naming be damned

    • do you want buggy, unstable software? because that’s how you get it.

      • I agree with Testure here, it’s the same reason why you never see Adobe or (most) major videogame companies doing it. The only platform that does this would be the phone apps, those things constantly update to the point where each update feels like a bland change to one or two mechanics.

    • There’s two separate things here. The frequency of releases, and how long it takes from a feature to go from implementation to a release.

      For stability of big new features, I think we really need those 2-3 months from initial commit to release. Something that works entirely fine for one user often causes problems for another. There are also steps like writing documentation and translation that need time.

      Firefox has been on a 6-8 weeks release schedule and is now switching to monthly. That’s accomplished by having 3 branches in development at any given time. We’re trying 2 now and will see how it goes. Maybe it works well and we can release more frequently. It would help get minor changes and bug fixes released faster.

      But there is also a significant cost to managing that kind of thing. Firefox has a release engineering team of 13 people, which is almost as big as our development team as a whole. We wouldn’t need that many, but we don’t even have 1 developer fully dedicated to this task.

    • What Blender developers doing is right IMO, 3 to 4 months is the sweet spot new features need testing and fixing if you get like 2-3 releases that would be overwhelming for people as you have to install new versions on top of each other all the time, if users want latest features then they should either download the buildbot builds or compile blender themselves, Persoanlly i don’t even mind if releases are 6 months apart that means tons of features who got polished before they are ready to use for actual projects.

      • Agree with 6 months if that will result in more polished features.

  2. There is a serious problem when editing and undo on heavy poly mesh, so far not seen you guys do anything about it, blender wouldn’t be true industry standard as long as you don’t fix it

  3. I like that Bcon3 and Bcon1 of next release co-exist. Hopefully it will allow delivering new releases faster without sacrificing quality of final releases 🙂 Thanks for the explaining this!

  4. Thanks for the article! I didn’t know anything about this “bcon” stuff (very interesting). Thanks for your hard work Blender Team! 😀 😀 😀

  5. Please, please do something to support Metal 2 on Mac OS. Yes, I’ve read all the explanations—and I still say, if there is will, there is a way. It BF themselves can’t manage it, maybe Apple would: after all, Blender is a good marketing vehicle to promote their new API. It doesn’t have to be free, either: just reasonably priced.
    But please, please don’t force me and other Mac Blenderheads on Windows. It’s bad enough that Apple can’t resolve their kindergarten spat with NVIDIA and at the very least, support the NVIDIA cards in eGPUs: I’d hate to think that BF is also succumbing to the ideology epidemics (like, ‘good’ open source vs. ‘evil’ corporations), while the users suffer.

    • I agree with Anarchymedes. Blender must consider Metal support if not directly possible then at least in some other ways. Many studios like me use macs, and we also use blender.

  6. To be honest I think 2.79 was fantastic and I’ve stuck with that as lots of my plugins didn’t work with 2.80 and the latter left me kind of bewildered anyway with all the changes. I guess it depends on just how realistic you need things to be, or how fast you need to work. I’ll try 2.81 when it’s declared completely stable and the plugins I need like Animall all work, but I’m in no rush.

  1. Leave a Reply

    Your email address will not be published. Required fields are marked *

     

share this story on