Process/Release Cycle

Release Cycle

Release Dates and Schedule

For information on the release dates of specific Blender versions, see the milestones on

2.8x Release Cycle

A new Blender version is targeted to be released every 3 months. The actual release cycle for a specific release is longer, and overlaps the previous and next release cycle.

Blender release cycle 01.png


Work is done in two branches:

  • blender-v{VERSION}-release branch: bug fixing only for the upcoming or LTS release
  • master branch: new features and improvements for the release after that

The blender-v{VERSION}-release branch will be available for 5 weeks prior to the release date. At the same time master will be open for the next release, giving 2 months to add new features for the next release, and another month to improve them.

Bcon Phases

Each Blender version has its own Bcon phase, indicating which types of changes are allowed to be committed and what developers are focusing on.

That means for example that Blender 2.81 can be in Bcon3 (bug fixing only) while Blender 2.82 is in Bcon1 (open for new features).

Phase Description Duration Details Branch Splash Shows
Bcon1 New features and changes 5 weeks Add bigger features and merge branches. Risky changes that are likely to cause bugs or additional work must be done before the end of this phase.

The first 5 weeks overlap with the Bcon3 & Bcon4 phases of the previous release, and many developers will focus on bug fixing in those first weeks.

Developers dedicate a steady 1-2 days/week to the bug tracker, focusing on triaging and newly introduced bugs.
master Alpha
4 weeks
Bcon2 Improve and stabilize 4 weeks Work to improve, optimize and fix bugs in new and existing features. Only smaller and less risky changes, including small features, should be made in this phase.

If a new feature is too unstable or incomplete, it will be reverted before the end of this phase.

Developers spend 2-3 days/week in the bug tracker, triaging, fixing recently introduced or prioritized module bugs.
master Alpha
Bcon3 Bug fixing only 5 weeks Focus on bug fixing and getting the release ready.

Development moves to the blender-v{VERSION} stabilizing branch and the splash screen gets updated. In master Bcon1 for the next release starts. blender-v{VERSION}-release is regularly merged into master.

The Python API remains stable during this phase, so add-ons have time to update before the release.

High priority bugs dictate how much time developers will spend in the tracker as oppose to work on the next release Bcon1 features.
blender-v{VERSION}-release Beta
Bcon4 Prepare release 1 week Stable branch is frozen to prepare for the release. Only critical and carefully reviewed bug fixes allowed.

Release candidate and release builds are made.

Developers spend a short time 5 days/week with an eye in the tracker for any unexpected high priority regression.
blender-v{VERSION}-release Release Candidate
Bcon5 Release 1-2 days Stage where the final builds are packaged for all platforms, last tweaks to the logs and promotional images, social media, video announcements.

The final switch is flicked on for the new release to show up in the Download page.
- -
Bcon6* Long-term release 2 years Critical fixes from master are ported over after passing quality assurance tests. blender-v{VERSION}-release

* Bcon6 only happens for LTS releases.

(Test) Build Schedule

For 2.81 and onward there won't be special RC releases as such. Rather testing is to be done using builds generated by our buildbots. The Windows ZIP archive releases are already properly signed. Code-signing and notarization for the MacOS builds is still being worked on.