Skip to content

Release Procedure

Benjamin Délèze edited this page Jun 28, 2023 · 96 revisions

Pre-release tasks

  1. Nominate a Release Leader, this leader should:

    • Make sure to understand the availabilities of everyone for the release.
    • Create the Github milestone for the next release.
    • Assign remaining issues.
    • Assign testing OS for the QA tests.
    • Create the QA as a google docs spreadsheet based on this template.
    • Make sure that everything is ready before the actual release (blog post [major releases only], announcement, etc.).
    • Know during the whole release process at any time who is doing what.
    • At least every day:
      • Check the progress of everyone.
      • Report overall release status to the whole team.
      • Re-assign remaining issues depending on progress.
  2. [major releases only] Write a blog post announcing the new release, see this example, the newsletter and twitter/Discord/etc. announcement. The blog post can be merged without the release date. Its update takes place once the release is ready (see Release tasks).

  3. Make sure that all the remaining issues corresponding to the release milestone are well sorted according to these rules:

    1. Regressions and other important issues such as crashes should be fixed for the next release.
    2. Depending on the urgency to release, eventually postpone the other issues and create new milestones.
  4. Update the doc:

    1. Regenerate thumbnails with docs/generate_thumbnails.py
    2. Update changelog files for the release if necessary (e.g. merge previous and current year, etc.).
  5. [major releases only] Update all the worlds and check for unwanted warnings by running the tests/test_worlds.py script (may take a long time).

  6. If new robots/simulations are available, eventually improve the guided tour.

  7. Perform tests (first iterations can be done on the last nightly build of develop):

    While (issues are reported):

    1. Fix every remaining issues having the corresponding milestone (eventually postpone the resolution of minor and the non-regressions issues)

    2. Sort ChangeLog entries in order of importance.

    3. Create the package and share it with testers. Merge the develop branch into master branch. Then, create a tag with the last commit on the Webots repository. Example:

      cd ~/webots
      git checkout master
      git pull origin master
      git tag -a R2021a -m "Webots R2021a"
      git push origin R2021a
      

      GitHub Actions will then create the packages and upload them to a new release. Alternatively, you can create the package yourself:

      cd ~/webots
      make clean
      make distrib -jX
      # the package is generated into `~/distribution/`.
      

      The tag should be created on the webots-snap and webots-docker repositories too, this will create the corresponding packages.

    4. Perform the QA test preferably on a clean computer.

Release tasks

When there is no more issues to fix and the current pre-release is ready to be deployed.

  1. Run scripts/new_version/new_version_file_headers.sh to make sure that all the WBT and PROTO headers are up-to-date with the current version.
  2. Open a PR to:
    • Regenerate the automatically generated files (doc and translation files). Type make clean and make update in the resources/translations folder.
    • Update the release date in the change log and the blog post.
  3. Merge master in released (this will publish the blog post if any).
  4. Upload the webots/resources/web/wwi files to https://cyberbotics.com/wwi/R2021a/ (replace R2021a with the actual release).
  5. Update Cyberbotics's web site: webots_current_version.txt
  6. Publish the snap package on the release channel on snapcraft.io following these instructions.
  7. Update the debian repository on cyberbotics.com/debian from a Linux machine, check Cyberbotics passwords for the GPG passphrase, do not upload the big .deb file to cyberbotics.com/debian/binary-amd64
mkdir debian
cd debian
mkdir binary-amd64
cd binary-amd64
wget https://github.com/cyberbotics/webots/releases/download/R2021a/webots_2021a_amd64.deb
cd ..
apt-ftparchive packages binary-amd64 > binary-amd64/Packages
cd binary-amd64
gzip -c Packages > Packages.gz
bzip2 -c Packages > Packages.bz2
echo "Archive: stable" > Release
echo "Component: main" >> Release
echo "Origin: Cyberbotics Ltd." >> Release
echo "Label: Cyberbotics Ltd. Debian repository" >> Release
echo "Architecture: amd64" >> Release
echo "Codename: binary-amd64" >> Release
apt-ftparchive release . >> Release
rm -f Release.gpg
gpg -abs --batch --passphrase-file ~/.gnupg/passphrase.txt -o Release.gpg Release
gpg --clearsign --output  InRelease Release

Post-release tasks

  1. Switch the Github tag from draft to release.
  2. Close the corresponding Github milestone.
  3. Announce the release on:
    • Twitter
    • Discord
    • LinkedIn
  4. Announce the release privately to the users waiting for it.
  5. Update Wikipedia (at least the release): https://en.wikipedia.org/wiki/Webots
  6. Update the version on the webots repo.
  7. In the released branch, update the urls that are not updated by scripts/new_version/new_version.sh (commented files).
  8. Check that the documentation serves the correct files. jsDelivr caches the files up to 24h so it may be necessary to purge the cache manually: https://github.com/cyberbotics/cyberbotics/blob/master/wiki/How-to-purge-jsDelivr-cache.md
  9. Update the other repos:
  10. Add a new UTM image to the webots_ros2 wiki, in the macOS installation instructions. The new image should contain the new webots_ros2 release, compatible with the new version of Webots (e.g. version 2023.0.0 for Webots R2023a).
  11. Update the online demos to work with the new version:

[major releases only]:

  1. Announce the release on:
  • robotics-worldwide mailing list.
  • euron-dist mailing list.
  • ROS discourse.
  • Reddit.
  • HackerNews.
  • cyberbotics newsletter.
Clone this wiki locally