Maintainer information#
Making a release#
For branch organization we use a variation of the GitHub
Flow with
the latest release branch named stable
(due to ReadTheDocs constraints).
Release Instructions#
From the root directory of the repository run
./tools/bump_version.py --new-version <new_version> # ./tools/bump_version.py --new_version <new_version> --dry-run
and check that the diff is correct with
git diff
. Try usingripgrep
to make sure there are no extra old versions lying around e.g.,rg -F "0.18"
,rg -F dev0
,rg -F dev.0
.Make sure the change log is up-to-date. (Skip for alpha releases.)
Indicate the release date in the change log.
Generate the list of contributors for the release at the end of the changelog entry with,
git shortlog -s LAST_TAG.. | cut -f2- | grep -v '\[bot\]' | sort --ignore-case | tr '\n' ';' | sed 's/;/, /g;s/, $//' | fold -s
where
LAST_TAG
is the tag for the last release.
Make a PR with the updates from steps 1 and 2. Merge the PR.
(Major release only.) Assuming the upstream
stable
branch exists, rename it to a release branch for the previous major version. For instance if last release was,0.20.0
, the corresponding release branch would be0.20.X
,git fetch upstream git checkout stable git checkout -b 0.20.X git push upstream 0.20.X git branch -D stable # delete locally
Create a tag
X.Y.Z
(without leadingv
) and push it to upstream,git tag X.Y.Z git push upstream X.Y.Z
Wait for the CI to pass and create the release on GitHub.
(Major release only). Create a new
stable
branch from this tag,git checkout -b stable git push upstream stable --force
Revert the release commit. If making a major release, increment the version to the next development version specified by Semantic Versioning.
# If you just released 0.22.0, then set the next version to 0.23.0 ./tools/bump_version.py --new-version 0.23.0.dev0
Update these instructions with any relevant changes.
Making a minor release#
For a minor release, commits need to be added to the stable
branch, ideally via a PR.
This can be done with either,
git cherry picking individual commits,
git checkout stable git pull git checkout -b backport-branch git cherry-pick <commit-hash>
or with interactive rebase,
git fetch upstream git checkout stable git pull git checkout -b backport-branch git rebase -i upstream/main
and indicate which commits to take from
main
in the UI.
Then follow the relevant steps from Release Instructions.
Making an alpha release#
Name the first alpha release x.x.xa1
and in subsequent alphas increment the
final number. Follow the relevant steps from Release Instructions.
Fixing documentation for a released version#
Cherry pick the corresponding documentation commits to the stable
branch. Use
[skip ci]
in the commit message.
Upgrading pyodide to a new version of CPython#
For example: v3.11.1
-> v3.11.2
Download the Gzipped source tarball at https://www.python.org/downloads/release/python-3112 into
downloads/
shasum -a 256 downloads/Python-3.11.2.tgz > cpython/checksums
git grep --name-only "3.11.1"
# All these files will need to be updated.After updating the Python version in
Dockerfile
, create a new Docker image.A maintainer must click
Run workflow
on https://github.com/pyodide/pyodide/actions/workflows/docker_image.yml
That workflow will build and upload a new Docker image to https://hub.docker.com/r/pyodide/pyodide-env/tags
Modify the image name in
.circleci/config.yml
to match the image tag on Docker Hub.image: pyodide/pyodide-env:20230301-chrome109-firefox109-py311
Modify the
PYODIDE_IMAGE_TAG
inrun_docker
to match the image tag on Docker Hub.PYODIDE_IMAGE_TAG="20230301-chrome109-firefox109-py311"
Rebase any patches which do not apply cleanly.
Create a pull request and fix any failing tests. This may be complicated for major releases of CPython.