The currently applied release cycle with 3 releases a year was established in 2023. It was tweaked later by renaming the BCON phases to common terms (Alpha, Beta…). The latest version is described in Developer Docs: Release Cycle.
The basic structure of the release cycle is clearly defined. But there is a certain gap between the releases on one side, and projects and special efforts on the other (the yearly libraries/VFX Platform update, the “Winter of Quality”, etc.).
Proposed Changes
The goal is:
To keep major releases (with potential major breakages) every other year, while allowing less critical ones (in particular linked to dependencies updates, and when necessary at the API level) on a yearly basis.
To gather all major risks/breakages into a single release per year.
To ensure that the LTS release is the most stable one of the year.
We keep releasing three times a year, at the same dates:
March: Platform update release.
Updates in sync with the yearly new VFX Reference Platform specs (libraries, but also sometimes C++ version, minimum OS or hardware requirements, etc.).
Every two years (new major version number like 6.0, 7.0…):
Potential major compatibility breakages.
Huge refactors of some data types.
Dropping support for very old data (e.g. animation data from 2.4x era).
Every year:
Best effort is made to keep the API compatible along the whole two years of a release cycle. But in case minor breakages are necessary, they should happen after the LTS, and be properly documented as deprecated in the LTS itself.
July: Regular release with new features.
November: Long-Term Support, focused on stability and maintainability.
Related Changes
The “Winter of Quality” will be discontinued, quality and stability should be a constant ongoing effort, part of every module’s work.
Further tweaks to the release development cycle may also be discussed during 2026 (e.g. to extend the Beta phase). These will not affect the release dates themselves.
Transition
Here is the proposed schedule to transition to this updated release cycle:
2026: nothing changes (5.1 new libs; 5.2 LTS; 5.3 regular)
2027: transition year, 2 releases only (5.4 new libs; 5.5 LTS)
Both 5.4 and 5.5 will get longer release cycles, with largely extended Beta phases.
2028: new schedule (6.0 new libs; 6.1 regular; 6.2 LTS)
6.0 will get a longer Alpha phase (roughly 6 months instead of 4).
A concern could be that there is no ideal release for bigger/riskier projects. Sometimes these projects cannot be break down in smaller user-focused sub-projects and will be given to the user in a single go. My concern is that:
March release has already many updates, adding another one on top of that makes it harder to find root causes of potential bugs. Additional timing might be needed for stabilization
July release is during summer holiday right before bcon. There is already pressure on the HQ personal. potential bugs will require more lead-time to be solved, leading to more work for triagers.
November release is an LTS release and should be focused on stability.
My best guess is to land bigger projects only for the March release on top of the many others or the July release with a known stability risk.
Landing larger features can be done for both the March and July release, and should not be done for LTS releases. So the only real change here is that LTS being done in November now rather than July.
These goals are at odds with each other, one major driver for compatibility breakage for end users is the python version we ship which is driven by the vfx platform, which could break at any given year even years we decide would be “a safe year”
Given we never really followed semantic versioning strictly anyhow and have plenty of “minor” breakage across the various releases, i’d almost lean towards giving up the semantic looking version numbers and follow ubuntu’s versioning year.month and be done with it.
It could yes - but in practice Python is pretty good with its backward-compatibility, so not sure we have had any serious breakage in the recent years? And usually, as it uses deprecation mechanisms, we should be able to always keep serious breaking changes for the major .0 releases.
Otherwise, if some deps upgrades on a .3 release introduces major breakages, I guess it’ll be an interesting discussion topic in the team.
It could yes - but in practice Python is pretty good with its backward-compatibility, so not sure we have had any serious breakage in the recent years?
It’s not as much breakage in python script, but it’s the binary wheels that cause the issue here, they’ll link to python310.dll/python311.dll/etc so when we bump, a whole lot of addons that rely on a binary component break.
An easy win here that would be very beneficial for studios/add-on authors would be to just communicate when Py Versions are going to jump in some form. I have suffered some negative consequences from being unaware of Py Version jumps (5.1 in Python 3.13). This wasn’t included in the release notes at the time 5.1 went into beta. I have contributed that info.
As far as I can tell the only way to know when Python versions jump is to be active on the forums and reading all the latest commits. Happy to be corrected on this fact.
I agree this isn’t communicated well right now, but the updated release proposal from the first post will make this clearer. Release Cycle - Blender Developer Documentation can be updated already to include more info, I will take care of it.
Basically every March release will have new major library versions. That does not necessarily mean there will be a new Python version every year, CY2024 and CY2025 were both on 3.11.x for example.
Cool! So just knowing every march Blender will match the python version (and other libs) of the vfx platform. Is exactly all that needs to be said. We can go to the VFX Platform to learn explicitly what version matches what year.
I agree this isn’t communicated well right now, but the updated release proposal from the first post will make this clearer
By the nature of the vfx platform, 2 times a year will never happen as that’s just not how it works (annual releases only) practically it means we bump yearly, for the daylies usually somewhere between November and January. Also no way to predict what the vfx platform will decide for any given year, so some years will have a python bump, some won’t.
Yeah I think the @ThomasDinges will/is doing already addresses the concern. And that statement is what I am asking for. Not expecting a crystal ball for when VFX platform will jump py versions. Just some clarity of when Blender may update to align with whatever the VFX platform is.
Just communication for whatever is known! As pipeline infrastructure is usually built around the python versions of whatever DCCs being used. VFX Platform helps us plan ahead and develop tools for upcoming releases.
