Release Checklist

What this covers

We use the following versioning scheme v6.MM/PP (text) or v6-MM-PP (git tag):

  • production releases have even numbers MM; development releases have odd numbers MM
  • releases always have even numbers PP; ROOT outside a tag has odd numbers PP
  • release candidates have -rcN attached, with N starting with 1 and counting up, e.g. v6-22-00-rc1 is the first release candidate for v6.22/00.

See also ROOT versioning scheme for a more public-facing description.

This page covers the following:

  • Creation of release branches: production releases (v6.22/06) are always tags on a release branch (v6-22-00-patches).
  • Releases: tags and binaries.

Create a production release branch from master

This assumes you try to create v6-22-00-patches, adjust accordingly.

  1. Create the branch point
    • check out master
    • this requires a new development release, follow “Produce a new ROOT release” below
    • tag the most recent version update on master ("Update ROOT version files to v6.23/01.") as v6-23-01 to give some context to git describe.
  2. Create the release branch
    • for root.git:
      • check out the development release tag: git checkout v6-23-02
      • create the branch: git switch -c v6-22-00-patches
    • for roottest.git:
      • check out master
      • create the branch: git checkout -b v6-22-00-patches
  3. Update version number
    • Change build/version_number to 6.21/99 in preparation of v6.22/00.
    • Run from the build directory $ cmake .; make version
  4. Tag the release candidate: git tag -a v6-22-00-rc1
  5. Push tags and branches
    • git push origin v6-22-00-patches (for root.git and roottest.git)
    • git push origin v6-23-01
    • git push origin v6-22-00-rc1
  6. Create the Jenkins procedures
    • on New Release Job state root-release-6.22 as “item name” and set (all the way at the bottom) “Copy from” to the release before (root-release-6.20 in the v6-22 example case); “Add to current view” should be set.
      • in “This project is parametrized” / “Validating String Parameter” / “VERSION”, put “v6-22-00-patches” as “Default Value”
      • in “Configuration Matrix” / “User-defined Axis” / “V”, put “6-22” as “Values”
      • adjust Node/Label / Labels as needed, update the “Matrix Combination Parameter” COMBINATIONS accordingly (you need to click “Advanced…” to actually see it)
    • on New Nightly Job state root-nightly-v6-22-00-patches as “item name” and set (all the way at the bottom) “Copy from” to the release before (root-nightly-v6-20-00-patches in the v6-22 example case); “Add to current view” should be set.
      • Update its values as for the release procedure.

Produce a new ROOT release

  1. Get the ‘green’ light from all main developers
  2. Check that all the Jenkins nightlies and Jenkins release builds builds are green
  3. Run with valgrind on python tutorials/pyroot/, tree/dataframe/test/dataframe_concurrency, and ./roofit/roofit/test/testRooParamHistFunc; make sure no memory errors are reported after applying --suppressions=$ROOTSYS/etc/valgrind-root.supp and --suppressions=$ROOTSYS/etc/valgrind-root-python.supp
  4. Verify that no performance regressions exist in the benchmark system
  5. If this is not a development release nor a release candidate, update the release notes in README/ReleaseNotes/vXXX/ If this is a patch release, edit release notes patches section at the end of the document.
    • Insert the list of fixed bugs and enhancements etc behind the general release announcement for that version. They come from both Jira and Github:
    • Jira project management
      • Create the next patch (“6.22/02”) or major (“6.24/00”) version in the project configuration
      • ‘Release’ the version you want to release, assigning open issues to the next patch or major release.
      • From the list the versions in JIRA, select the version and then ‘release notes’
    • GitHub project management
      • Run python3 ./ --project-name 6.22/02 to copy and paste the fixed GitHub issues into the release notes.
      • Go to this version’s GitHub project (e.g. Fixed in 6.22/08 when releasing 6.22/08). On the right column header, click “<” until the column header reads “Menu” with a hamburger menu next to it. Below, to the right, you see “…”. Click, select “Copy”, and enter the name of the next production or patch release. Don’t forget to remove the leading “[COPY]”! Owner is root-project/root.
      • In “…” next to the currently to-be-released version’s GitHub project, hit “Close project”. (No more bugs will be fixed in it: we are releasing it!)
    • Commit your new release notes: git commit README/ReleaseNotes/v622/
  6. Update version number
    • Edit build/version_number. For release candidates, leave the version number at the development release number corresponding to the -rc1 candidate.
    • Run from the build directory $ cmake . && make && make version
  7. Tag main ROOT repository
    • git tag -a v6-22-02
  8. Git pull and git tag ROOTTEST repository
  9. Make source tar file and copy to ftp area on
    • Run from the build directory $ make distsrc not on a MacOS machine
    • scp ../root_vX.YY.ZZ.source.tar.gz sftnight@root:/var/www/root/download/
  10. For non-patch releases, create new release notes in README/ReleaseNotes/vXXX+1/
    • Copy from README/ReleaseNotes/, adjust version numbers.
    • git commit README/ReleaseNotes/vXXX/
  11. Update to the next development version
    • Edit build/version_number (odd patch number)
    • $ cmake . && make version
  12. Fix build errors!
    • Deprecations will now create build errors, fix them
    • make must succeed
  13. Push to GitHub
    • git push origin v6-22-02
  14. Update the stable branch. The command below creates a commit that appears as a merge to git porcelain commands, but that directly points to the tree given by the LATEST_STABLE commit-ish. Users that have cloned this branch will receive updates as a fast-forward via git pull
    • $ LATEST_STABLE=v6-xx-yy # e.g. v6-22-02
    • $ git fetch origin latest-stable:latest-stable
    • $ git update-ref refs/heads/latest-stable $(git commit-tree $LATEST_STABLE^{tree} -p refs/heads/latest-stable -p $LATEST_STABLE^{commit} -m "Updated 'latest-stable' branch to $LATEST_STABLE")
    • $ git push origin latest-stable
  15. Produce binary tar-files (optional for development releases and release candidates)
  16. Install binaries to CVMFS (optional for development releases and release candidates)
  17. Update the release pages (optional for development releases and release candidates)
    • Generate the release notes with the Jenkins procedure called root-releasenotes with v6-22-00-patches or similar as version. They’d show up here for v6.22.
    • Wait until the files show up on a machine with cvmfs, e.g. lxplus, in /cvmfs/
    • On that machine with cvmfs, create a new release web page with the script python3 _releases/ _releases/ in ROOT’s website repo.
    • Add a ‘highlights’ section in the generated release page.
    • If this applies, mark the release as state: latest and remove the attribute to the one previously holding it (git grep "state: latest" -- _releases/)
    • Create a PR against root-project/web.
  18. Update the list of build options
    • cd into main directory of the root-project/web repository.
    • Run bash _releases/ v6-22-00-patches. This creates the file _includes/
    • Modify the install/ file, appending the created file above to the list of build options dropdown items. Look for tags like <details markdown="1"><summary markdown="span"> and add the file at the end.
    • Run git checkout -b build-options-v622; git add _includes/ install/; git commit; git push and open a PR on the web repository.
  19. Announcements
    • Send mail to the following mailing lists:,,,
    • Write announcement in RootTalk forum news (optional for development releases and release candidates)
    • For new major releases, consider writing a blog post for announcing the highlights.