Skip to content

Commit 126193d

Browse files
authored
DOC Add instructions for making a release (pyodide#1533)
1 parent 299e4d9 commit 126193d

File tree

4 files changed

+102
-1
lines changed

4 files changed

+102
-1
lines changed

‎docs/development/contributing.md‎

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -99,6 +99,10 @@ All code submissions should pass `make lint`. Python is checked with the
9999
default settings of `flake8`. C and Javascript are checked against the Mozilla
100100
style in `clang-format`.
101101

102+
### Contributing to the “core” C Code
103+
104+
See {ref}`contributing-core`.
105+
102106
## Documentation
103107

104108
Documentation is a critical part of any open source project and we are very
@@ -137,6 +141,9 @@ If patches fail to apply automatically, one solution can be to
137141
```
138142
git format-patch -<N> -N --no-stat HEAD -o <out_dir>
139143
```
144+
## Maintainer information
145+
146+
For information about making releases see {ref}`maintainer-information`.
140147

141148
## License
142149

@@ -153,3 +160,11 @@ clarification on what is and isn't permitted.
153160
- __Gitter:__ [#pyodide](https://gitter.im/pyodide/community) channel at gitter.im
154161

155162
[tl;drLegal entry]:https://tldrlegal.com/license/mozilla-public-license-2.0-(mpl-2)
163+
164+
```{eval-rst}
165+
.. toctree::
166+
:hidden:
167+
168+
core.md
169+
maintainers.md
170+
```

‎docs/development/core.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,4 @@
1+
(contributing-core)=
12
# Contributing to the "core" C Code
23

34
This file is intended as guidelines to help contributors trying to modify the C source files in `src/core`.

‎docs/development/maintainers.md‎

Lines changed: 86 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,86 @@
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.

‎docs/index.rst‎

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -42,7 +42,6 @@ and understanding type conversions between Python and JavaScript.
4242
development/building-from-sources.md
4343
development/new-packages.md
4444
development/contributing.md
45-
development/core.md
4645
development/testing.md
4746
development/debugging.md
4847

0 commit comments

Comments
 (0)