Process/Release Checklist

Release Checklist

This is a checklist to go over when making release, to ensure everything has been updated.

Start New Release Cycle

When the release transitions to the stabilizing branch at the start of bcon3.


  • Check with Sergey Sharybin that pushing of new branches is possible
  • Create blender-v2.XX-release branches for the following repositories:
    • Blender (rB)
    • Addons (rBA, /release/scripts/addons)
    • Addons Contrib (rBA, /release/scripts/addons_contrib)
    • Translations (rBT, /release/datafiles/locale)
    • Blender Dev Tools (rBDT, /source/tools)
git checkout -b blender-v2.XX-release
git push origin blender-v2.XX-release
  • Create blender-2.XX-release tag for Libraries (rBL)
svn mkdir
svn copy
  • Create blender-2.XX-release branch for the Manual (rBM)
svn mkdir
svn copy
  • In the master branch, bump the version in:
    • PROJECT_NUMBER in doc/doxygen/Doxyfile
    • BLENDER_VERSION, BLENDER_SUBVERSION in source/blender/blenkernel/BKE_blender_version.h
  • In the release branch, set BLENDER_VERSION_CYCLE to beta.
  • Do an actual subversion bump if needed to have everything properly organized in our doversion code.
    • I.E. block with /* Versioning code until next subversion bump goes here. */ comment should be empty.
    • Both blo_do_versions_xxx and do_versions_after_linking_xxx have to be checked.
  • Splash screen
    • Don't push this change before talking to the PR team - we announce to the world in social media at the same we commit the splash to the source code.
  • Merge the release branch into master, ensuring BKE_blender_version and the splashscreen remains correct.
  • Update master.cfg in blender-buildbot.git to enable the release branch for nightly builds
  • Update source/rules.php in blender-buildbot-www.git, so that the version is marked as beta and LTS when applicable
  • Force build both branches on buildbot, and ensure they are both visible on the download page.


  • Create empty release notes for next release on and
  • Change buildbot configuration to build new release branch
  • Update dashboard on
  • Update bcon in topic
  • Add a new release notes redirect (e.g., ->


Preparation for the final release:


  • Make a dedicated channel on to handle release communication
  • At least one hour before going to BCon5, send message to bf-committers and check with available core developers online that everything looks good for release.
    • Do not do that outside of reasonable work hours CET (10:00-17:00), nor during lunch break (13:00-14:00).
    • Ensure i18n (rBT, /release/datafiles/locale) is updated. Notify Bastien Montagne/mont29 so he can update the files prior to final release commits
  • Move Blender to bcon5 status:
  • Send message to bf-committers to notify about impending release commits
  • Create a Potential candidates for corrective releases task tagged with the released version


  • Update release list in release/freedesktop/org.blender.Blender.appdata.xml
  • Make sure the libraries versions are updated in release/license/THIRD-PARTY-LICENSES.txt
  • Do an actual subversion bump if needed to have everything properly organized in our doversion code.
    • I.E. block with /* Versioning code until next subversion bump goes here. */ comment should be empty.
    • Both blo_do_versions_xxx and do_versions_after_linking_xxx have to be checked.
  • Version bump (in release branch)
    • BLENDER_VERSION_CYCLE in BKE_blender_version.h
  • Tag repositories (only after the build is approved):
    • blender (rB)
    • addons (rBA, /release/scripts/addons)
    • addons_contrib (rBAC, /release/scripts/addons_contrib)
    • i18n (rBT, /release/datafiles/locale)
    • tools (rBDT /source/tools)
git tag -a v2.82 -m "Tagging Blender 2.82 release"
git push origin v2.82
    • The following are not tagged: i18n SVN (rBTS), libraries (rBL)
    • The libraries (rBL) were tagged already at the start of the release cycle and do not need to be tagged again.
  • Sync and tag Cycles "stand-alone" repository (rC)


  • Run automated tests
  • Run manual tests

Release Builds

This procedure has changed to use Buildbot and automated scripts. Needs updating.
Check times when mirrors are updated. Aim to push files 1 hour prior to US update schedule.


    • Finish release notes
  • Ensure updated screenshots at
    • Release notes: adapt from wiki and add artwork
    • Add link to notes from the list of releases
    • Add splash file to demo-files page
    • Sitewide settings
      • Set Blender Version and release data
    • Front page
      • Add news item
    • Download page
      • Paths & Platforms tab
        • Update the File Path for every build in every platform.
        • E.g. blender-2.79b-windows64.msi -> blender-2.80-windows64.msi
      • Mirrors tab
        • Check mirrors have a copy of the file, otherwise disable them. (find the URLs below)
      • Splash & Release Notes tab
        • Update Release Features Summary, this text goes under the download section.
        • Update Splash Artwork, this shows up next to the Release Features Summary, doesn’t necessarily need to be the splash artwork, can be a cool screenshot too.
      • Announcement tab
        • This is a piece of HTML that can be displayed under the main download button. It could be used for adding a quick link to older versions.
      • Release Candidate
        • If RC is needed, set it up using similar settings as a regular release.
    • Credits page
      • Update using source/tools/utils/
  • Buildbot
    • Check that builds are shown correctly for the next release cycle



This procedure has changed to use Buildbot. Needs updating.

  • Freeze manual for release
    • This may be done some time after the release, if the manual team wants to keep improving the documentation.
    • On Manual builder VM, disable cron service to stop changes to the html files during move
    • On, edit and run the script.
      • Set LATEST_VERSION to the version of the release, and DEV_VERSION to the version in master, and run.
    • On Manual builder VM, enable cron service to resume changes
    • In the Blender manual repository:
      • Edit resources/versions.json to add an entry for the release, and change dev to point to the master version.
      • Update the version number in manual/
    • Afterwards the situation will be:
      • latest/ will point to the frozen manual of the release
      • dev/ points to the continuously updated docs for master.
  • Update API docs for final release version.
  • Check manual links are valid in Blender (see