Skip to content

Blender LTS

With the release of Blender 2.83, Blender Foundation started the LTS (Long Term Support) program. The program is aimed at predictability, ensuring that long-lasting projects can be executed using a stable Blender version which will provide bug fixes throughout a 2-year time span.

Backporting

Currently, for non-LTS releases, Blender only has a corrective release if high severity bugs are found. When the corrective release is agreed on however, other fixes may be backported as well.

For the LTS releases, a similar (but more restricted) policy applies: - A fix in the main branch has been tested there for some time to avoid followup issues (at least one week for trivial fixes or a month for technically complex changes, when unforeseen side-effects cannot reasonably be ruled out) - Blender's output (e.g. rendering) does not change - Python API does not change (so scripts will keep working) - Blend File Compatibility does not change - Libraries will only update to address CVEs - Any significant drop in performance (even if on a very specific sub-system or feature, e.g. a modifier, node or specific operator) should be avoided

In both cases (corrective releases and LTS releases) it is up to the committer to decide if a fix should be backported (if in doubt, after consultation with their module owners) with the release manager overseeing the process.

To help on the decision process (in which we try to be conservative, but also flexible and pragmatic, so in extreme cases exceptions to the above policy might even be considered), the "benefit, cost and risk" of a backport should be evaluated: - Benefits: Is it a critical fix for users? Or is it a significant quality of life improvement for users? Or 'just' a nice to have improvement, or a significant fix but in a very niche feature? - Costs: Does the improvement overweight potential annoyances (API breakage, change in Blender's output, Blend File Compatibility, performance impact)? - Risks: Is it trivial (like typos or oneliners), or does it potentially spread through half the code base? Does it affect a low-level piece of code used throughout Blender, or a high-level code only used by a specific feature/tool? Does the committer and/or the module fully understand the consequences of the change and are reasonably certain that there will not be unexpected side-effects?

Currently, candidates for backporting are gathered in "backporting lists", links to these can be found on the respective LTS milestone.

If important fixes are missing in LTS, it is possible to let us know in the mentioned lists, or contact the module responsible for releases

Distribution

The LTS releases (which happen at a fixed schedule - currently once each month if there are backports) will be added to the current roster of Blender releases available during the development cycle.

Bug-fix flow diagram

Currently, at the beginning of Beta, the main branch is forked into a release branch. Any bug fix relevant to the upcoming release happens in the release branch, and is merged to main.

For the LTS versions, their branches work as usual, but once the release happens they keep receiving critical updates. Such updates can be backported from main or be performed on the branch itself.

Version Communication

In order to clearly communicate how the growing number of Blender versions relate to each other, an updated version naming convention will be adopted:

  • Sub-version as corrective releases. Use 2.83.1 instead of 2.83a

Never expose to the users the internal sub-subversion numbering (e.g., 2.83.9). The complete version and the hash is enough for bug reporting.

  • Rename the development builds (currently 2.90 alpha) to allow better focus on the upcoming release (2.83). Instead of calling it "2.90 alpha", we call it development / master / daily / next / ... build.
  • builder.blender.org should feature exclusively (or distinctly) the master build