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.

Blender

  • 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 https://svn.blender.org/svnroot/bf-blender/tags/blender-2.XX-release
svn copy https://svn.blender.org/svnroot/bf-blender/trunk/lib https://svn.blender.org/svnroot/bf-blender/tags/blender-2.XX-release/lib
  • 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.
  • Merge the release branch into master, ensuring BKE_blender_version 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.

Websites

  • Create empty release notes for next release on wiki.blender.org and blender.org
  • Change buildbot configuration to build new release branch
  • Update dashboard on developer.blender.org
  • Update bcon in blender.chat topic

Release

Preparation for the final release:

Communication

  • Make a dedicated channel on blender.chat 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

Blender

  • Update release list in release/freedesktop/org.blender.Blender.appdata.xml
  • 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.
    • Starting on 2.91 the splashscreen was updated during bcon3 instead.
  • 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)

Tests

  • Run automated tests
  • Run manual tests

Release Builds

Websites

  • wiki.blender.org
    • Finish release notes
  • Ensure updated screenshots at https://download.blender.org/demo/screenshots/
  • Blender.org
    • 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/credits_git_gen.py
  • Buildbot
    • Check that builds are shown correctly for the next release cycle

Mirrors

Docs

  • 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 docs.blender.org, edit and run the freeze_version.sh 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/conf.py
    • 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 bl_rna_manual_reference.py)