|
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