Skip to content

Release Process

Jump to bottom
Azaya edited this page Dec 12, 2023 · 7 revisions

This describes the Bokeh release process. If it is not correct, please update it.

Before release

  1. Regular dev releases are useful to test the build and deployment process.

  2. A feature freeze should ideally occur at a specified date, e.g. 2 weeks before the planned release.

  3. Docs should be built, uploaded and checked. New issue to build staged version of docs prior to release?

  4. Issue hygiene status should be checked, i.e. what issues are targeted for the planned release. Possible new issue to weekly automate issue hygiene?

  5. Update version at switcher.json. Is this part of the docs build? Could add extra check somewhere in the process to check it has been updated with the current/impending version?

Actual release

  1. Run python scripts/milestone.py -a 3.3 locally to check the status of the milestone.

  2. Run the "Release - Build" action at https://github.com/bokeh/bokeh/actions. Select the action, click the "Run Workflow" button, select the branch to build and input the version tag as a string. Then click the colored "Run workflow" button.

    • This takes quite a while.
    • It updates the changelog, builds Bokeh, generates SRI hashes, commits those and tags the release. The tarball is uploaded to s3 and uploads BokehJS to CDN so that the build can be tested.
    • It is possible to download the tarball and install it locally to test.
    • If there is a problem during this process it can just be rerun. If the CDN upload has completed and is no longer required then it can be manually deleted.
    • New issue: change to use mamba?

  3. Run the "Release - Build" action at https://github.com/bokeh/bokeh/actions. This uploads sdist and wheel to https://pypi.org/project/bokeh and conda packages to the Bokeh channel at https://anaconda.org/bokeh/bokeh.

  4. Communicate release

    • On Discourse in the Announcements category.
    • Blog post.
    • Social media
      • Twitter
      • Discord
      • Bluesky/Mastodon?

  5. conda-forge: A conda-forge bot will automatically identify from PyPI that a new release has been made and create a PR at https://github.com/conda-forge/bokeh-feedstock. This needs to be reviewed and merged, and then packages will be built and made available automatically.

  6. Anaconda defaults channel: When the conda-forge build has succeeded, create a new PR at https://github.com/AnacondaRecipes/bokeh-feedstock to build for the Anaconda defaults channel. This needs to be reviewed and merged by someone with appropriate permissions at Anaconda. After the PR is merged the packages are not automatically built and uploaded; if this is taking a long time then someone in the HoloViz team will know who to contact to speed up the process.

After release

  1. Update tutorial repo to use new release. Probably should check it all runs OK?

  2. Create a new release branch. This may already have been done. Also merge latest changes from current release branch into it.

  3. Update default branch to new release branch.

  4. Manually update open PRs to target the new release branch.

  5. Start an initial dev build on the new release branch. This is needed for our version tool.

  6. Update the date of the milestone just released and close it (there should be no open issues or PRs assigned to it).

  7. Check and clean out any remaining dev/RC tags.

  8. Possibly clean out old dev/RC tarballs from the s3 deployments bucket.

Clone this wiki locally