Process/Release Checklist

= Release Checklist =

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

Start New Release Cycle
When the release transitions to the stabilizing branch at the start of bcon3.

I - Before Branching

 * Check with Sergey Sharybin that pushing of new branches is possible
 * 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.

II - Branching

 * Create `blender-v3.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`)
 * Create `blender-3.XX-release` tag for Libraries (`rBL`)
 * Create `blender-3.XX-release` branch for the Manual (`rBM`)

III - After Branching

 * In the `trunk` branch of the Manual, update the `blender_version` number in `manual/conf.py`.
 * In the master branch:
 * `PROJECT_NUMBER` in `doc/doxygen/Doxyfile`
 * `BLENDER_VERSION`, `BLENDER_FILE_SUBVERSION` in `source/blender/blenkernel/BKE_blender_version.h`
 * In the release branch:
 * Set `BLENDER_VERSION_CYCLE` to `beta`.
 * Update `build_files/config/pipeline_config.yaml` to point to the correct submodule and library branches.
 * Update and uncomment `BLENDER_VERSION` in `build_files/build_environment/cmake/download.cmake`.
 * Commit Splash screen to the release branch
 * 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.

Buildbot

 * Add tracks for new release branch in `cmd/buildbot/conf/branches.py` and `cmd/build/functions/build-branches.ps1`.
 * Remove folders for unused tracks on all buildbot machines, as there may not be enough disk space for the new track otherwise.
 * Push git repo to workers and masters, and reconfigure masters.
 * Force build `daily-coordinator`, `doc-api-coordinator` and `doc-manual-coordinator` for both `vdev` and the new release track.
 * Verify that builds succeeded and are available for download.

Websites

 * Create empty release notes for next release on wiki.blender.org and blender.org
 * Update dashboard on projects.blender.org
 * Update bcon in blender.chat topic
 * Add a new release notes redirect (e.g., blender.org/download/releases/X.X -> wiki.blender.org/wiki/Reference/Release_Notes/X.X)
 * Add a new Blender version milestone on Phabricator for the second next release.

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:
 * Update bcon5 status on #blender-coders @ blender.chat
 * Update bcon5 status on front page of projects.blender.org
 * Send message to bf-committers to notify about impending release commits
 * Create a Potential candidates for corrective releases task tagged with the released version. (For LTS releases, create a Blender LTS: Maintenance Task X.X instead)

Blender

 * 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`

Tagging
Tag repositories (only after the build is approved):
 * Tag submodules first:
 * `addons (rBA, /release/scripts/addons)`
 * `addons_contrib (rBAC, /release/scripts/addons_contrib)`
 * `i18n (rBT, /release/datafiles/locale)`
 * `tools (rBDT /source/tools)`
 * Commit and push updated references to the branch:
 * Tag the main repo `blender (rB)`


 * 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.

Release Builds

 * On the buildbot:
 * Trigger a `vXXX-code-daily-coordinator` build with package delivery.
 * Once finished, trigger `vXXX-code-store-coordinator` to upload builds to the stores and generate msix package
 * Manually tests builds.
 * Once ready to release, trigger `vXXX-code-artifacts-deploy-coordinator` to deploy the packages to download.blender.org and mirrors.
 * make source_archive_complete
 * Ensure mirrors are synced
 * Lock uploaded files on download.blender.org (`schg`). Ask Dan McGrath to do this, can't be done from inside jail.

Stores

 * Snap
 * Final builds should be uploaded at this point, but not yet released as stable
 * Close beta and edge for this release.
 * Close candidate for previous release, if not an LTS.
 * Promote candidate channel to stable for this release.
 * Update latest/stable to match this release.
 * Steam
 * Final builds should be uploaded at this point, but not yet released in the stable branches
 * Create vX.X branch for this release and point it to the right build.
 * Point the default branch to the same build as vX.X.
 * If releasing an LTS, create a daily-X.X and devtest-X.X branch for the buildbot to push to automatically.
 * Do release announcement and any other store page changes.
 * Windows Store
 * Download msix package from download.blender.org and release it in the windows store.
 * Update store listings (export CSV, edit, import CSV again) with the PR release text

blender.org

 * Release Notes
 * Adapt from Wiki, add artwork
 * Write press release
 * Add Splash .blend file to demo-files page
 * Update Redirection from `/download/releases/{version}/` to `wiki.blender.org/wiki/Reference/Release_Notes/{version}`
 * Download page
 * Paths & Platforms tab
 * Update the Builds Folder and File Path for every build in every platform
 * E.g. `blender-3.1.2-windows-x64.msi` → `blender-3.2-windows-x64.msi`
 * 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 LTS versions.
 * Credits: Update page using `source/tools/utils/credits_git_gen.py`
 * Frontpage: Add news item
 * Release Notes: Add item to list of releases
 * Thanks page: Update artwork
 * Site-wide settings (this needs certain permissions only Pablo, Francesco, Dan have)
 * Set Blender Version and Release Date in Site-wide settings
 * Check mirrors have a copy of the file, otherwise disable those without. (find the URLs below)

LTS release
In the case of an LTS release, add a new row in Download → Long-term Support → Blender X.X LTS and fill with release notes from `generate-code-patch-notes` buildbot build step (can be run manually too, see `create_release_notes.py`)

wiki.blender.org

 * Finish Release Notes and update release phase.
 * Ensure updated screenshots at https://download.blender.org/demo/screenshots/

Docs

 * Buildbot:
 * Update `cmd/build/functions/build-branches.ps1` for stable doc version and manual version labels (for version switching menu).
 * Push git repo to workers.
 * Trigger `vdev-doc-api-coordinator` and `vdev-doc-manual-coordinator` on buildbot to update docs, afterwards check the links and version switch menu are correct.
 * Python API current is the new release
 * Manual latest is the new release
 * Check manual links are valid in Blender (see bl_rna_manual_reference.py)

Phabricator

 * Create new BF Blender milestone for next release, with initial dates for bcon stages.

Stores

 * Snap: request tracks for the next release to be created on snapcraft forum (with BlenderRelease account), so that we will have it by the time the next cycle starts

Buildbot

 * Once the release is out for a while and no bugfix release is planned, update buildbot configuration to remove the track corresponding to the release.
 * In case of an LTS release, keep the track around and remove an old LTS track if needed.

Cycles

 * Sync and tag Cycles "stand-alone" repository (rC)

Benchmark

 * Add release to the Blender Benchmark. More info in #blender-open-data.

LTS end-of-life

 * Update the LTS's page announcing the end-of-life, recommend to switch to the latest LTS. See 2.83 as reference.
 * Move the EOL release to "Previous LTS Releases" on blender.org

Mirrors
This is the complete list of mirrors, from which not all may be enabled for use at the moment. See the External Mirrors page in blender.org to find out which mirrors are currently enabled and ready to be used.


 * CN - Aliyun
 * DE - RWTH Aachen University
 * DK - Dotsrc.org
 * NL - blender.org
 * NL - Vereniging NLUUG
 * US - Clarkson University
 * US - Open Computing Facility at UC Berkeley
 * SG - Freedif Singapore (syncs hourly)