|
2 | 2 |
|
3 | 3 | ## Get `CONDA_EXE` |
4 | 4 |
|
5 | | -- Get [miniforge](https://github.com/conda-forge/miniforge) |
| 5 | +- Get [Mambaforge](https://conda-forge.org/miniforge/) |
6 | 6 |
|
7 | 7 | ```bash |
8 | | -conda install -c conda-forge doit |
9 | | - optional meta-dependencies |
10 | | -conda install -c conda-forge conda-lock mamba |
| 8 | +mamba install -c conda-forge doit |
| 9 | +# optional meta-dependency |
| 10 | +mamba install -c conda-forge conda-lock |
11 | 11 | ``` |
12 | 12 |
|
13 | 13 | ## Get the code |
@@ -51,36 +51,45 @@ developing, hoping for a better cache hit rate. On the same _operating system_, |
51 | 51 | however, any of the pre-solved lockfiles can be used, by specifying the |
52 | 52 | `RJFL_LOCKFILE` environment variable. |
53 | 53 |
|
54 | | -For example, if `linux-64` running `python3.6` with `jupyterlab 1` failed: |
| 54 | +For example, if `linux-64` running `python3.7` with `jupyterlab 1` failed: |
55 | 55 |
|
56 | 56 | ```bash |
57 | 57 | !/usr/bin/env bash |
58 | 58 | set -eux |
59 | | -RFJL_LOCKDIR=test/linux-64/py3.6/lab1 doit release |
| 59 | +RFJL_LOCKDIR=test/linux-64/py3.7/lab1 doit release |
60 | 60 | ``` |
61 | 61 |
|
62 | 62 | Or, in a `bat` script: |
63 | 63 |
|
64 | 64 | ```bat |
65 | 65 | @echo on |
66 | | -set RFJL_LOCKDIR=test/win-64/py3.9/lab1 |
| 66 | +set RFJL_LOCKDIR=test/win-64/py3.7/lab1 |
67 | 67 | doit release |
68 | 68 | ``` |
69 | 69 |
|
70 | 70 | This will recreate the `test` environment with the specified lockfile, and |
71 | 71 | repeat all the steps. |
72 | 72 |
|
73 | | -### Releasing |
74 | | - |
75 | | -- ensure `VERSION` has been increased appropriately |
76 | | -- ensure `HISTORY.ipynb` is up-to-date |
77 | | -- (usually) grab the `dist` assets from CI, unpack into `./dist` |
78 | | -- make a GitHub release, adding the `.tar.gz`, `.whl`, and `SHA256SUMS` |
79 | | -- upload to PyPI |
80 | | - |
| 73 | +## Releasing |
| 74 | + |
| 75 | +- [ ] merge all outstanding PRs |
| 76 | +- [ ] start a release issue with a checklist (maybe like this one) |
| 77 | +- [ ] ensure `VERSION` has been increased appropriately |
| 78 | +- [ ] ensure the `HISTORY.ipynb` is up-to-date |
| 79 | +- [ ] validate on binder |
| 80 | +- [ ] validate on ReadTheDocs |
| 81 | +- [ ] wait for a successful build of `master` |
| 82 | +- [ ] download the `dist` archive and unpack somewhere (maybe a fresh `dist`) |
| 83 | +- [ ] create a new release through the GitHub UI |
| 84 | + - [ ] paste in the relevant `HISTORY` entries |
| 85 | + - [ ] upload the artifacts |
| 86 | +- [ ] actually upload to pypi.org |
81 | 87 | ```bash |
82 | 88 | doit publish |
83 | 89 | ``` |
84 | | - |
85 | | -- do a post-mortem issue |
86 | | -- bump `VERSION` to a working status |
| 90 | +- [ ] postmortem |
| 91 | + - [ ] handle `conda-forge` feedstock tasks |
| 92 | + - [ ] validate on binder via simplest-possible gists |
| 93 | + - [ ] activate the version on ReadTheDocs |
| 94 | + - [ ] bump `VERSION` to next development version |
| 95 | + - [ ] update release procedures |
0 commit comments