|
| 1 | +(maintainer-information)= |
| 2 | +# Maintainer information |
| 3 | + |
| 4 | +## Making a release |
| 5 | + |
| 6 | +For branch organization we use a variation of the [Github |
| 7 | +Flow](https://guides.github.com/introduction/flow/) with |
| 8 | +the latest release branch named `stable` (due to ReadTheDocs constraints). |
| 9 | + |
| 10 | +(making-major-release)= |
| 11 | +### Making a major release |
| 12 | + |
| 13 | +1. Make a new PR and for all occurrences of |
| 14 | + `https://cdn.jsdelivr.net/pyodide/dev/full/` in `./docs/` replace `dev` with |
| 15 | + the release version `vX.Y.Z` (note the presence of the leading `v`). This |
| 16 | + also applies to `docs/conf.py` |
| 17 | +2. Set version in `src/pyodide-py/pyodide/__init__.py` |
| 18 | +3. Make sure the change log is up to date. |
| 19 | + - Indicate the release date in the change log. |
| 20 | + - Generate the list of contributors for the release at the end of the |
| 21 | + changelog entry with, |
| 22 | + ```bash |
| 23 | + git shortlog -s LAST_TAG.. | cut -f2- | sort --ignore-case | tr '\n' ';' | sed 's/;/, /g;s/, $//' | fold -s |
| 24 | + ``` |
| 25 | + where `LAST_TAG` is the tag for the last release. |
| 26 | + Merge the PR. |
| 27 | +4. Assuming the upstream `stable` branch exists, rename it to a release branch |
| 28 | + for the previous major version. For instance if last release was, `0.20.0`, |
| 29 | + the corresponding release branch would be `0.20.X`, |
| 30 | + ```bash |
| 31 | + git fetch upstream |
| 32 | + git checkout stable |
| 33 | + git checkout -b 0.20.X |
| 34 | + git push upstream 0.20.X |
| 35 | + git branch -D stable # delete locally |
| 36 | + ``` |
| 37 | +5. Create a tag `X.Y.Z` (without leading `v`) and push |
| 38 | + it to upstream, |
| 39 | + ```bash |
| 40 | + git tag X.Y.Z |
| 41 | + git push upstream X.Y.Z |
| 42 | + ``` |
| 43 | + Create a new `stable` branch from this tag, |
| 44 | + ```bash |
| 45 | + git checkout -b stable |
| 46 | + git push upstream stable --force |
| 47 | + ``` |
| 48 | + Wait for the CI to pass and create the release on GitHub. |
| 49 | +6. Build the pre-built Docker image locally and push, |
| 50 | + ```bash |
| 51 | + docker build -t pyodide/pyodide:X.Y.Z -f Dockerfile-prebuilt --build-arg VERSION=BB . |
| 52 | + docker push |
| 53 | + ``` |
| 54 | + where `BB` is the last version of the `pyodide-env` Docker image. |
| 55 | +7. Revert Step 1. and increment the version in |
| 56 | + `src/pyodide-py/pyodide/__init__.py` to the next version specified by |
| 57 | + Semantic Versioning. |
| 58 | + |
| 59 | +### Making a minor release |
| 60 | + |
| 61 | +For a minor release, commits need to be added to the `stable` branch, ideally via a PR. |
| 62 | +This can be done with either, |
| 63 | + - git cherry picking individual commits, |
| 64 | + ```bash |
| 65 | + git checkout stable |
| 66 | + git pull |
| 67 | + git checkout -b backport-branch |
| 68 | + git cherry-puck <commit-hash> |
| 69 | + ``` |
| 70 | + - or with interactive rebase, |
| 71 | + ```bash |
| 72 | + git fetch upstream |
| 73 | + git checkout stable |
| 74 | + git pull |
| 75 | + git checkout -b backport-branch |
| 76 | + git rebase -i upstream/main |
| 77 | + ``` |
| 78 | + and indicate which commits to take from `main` in the UI. |
| 79 | + |
| 80 | + |
| 81 | +Then follow steps 2, 3, and 6 from {ref}`making-major-release`. |
| 82 | + |
| 83 | +### Fixing documentation for a released version |
| 84 | + |
| 85 | +Cherry pick the corresponding documentation commits to the `stable` branch. Use |
| 86 | +`[skip ci]` in the commit message. |
0 commit comments