|
| 1 | +# How to do a vpython release |
| 2 | + |
| 3 | +There are two things that need to be released: |
| 4 | + |
| 5 | ++ The Python package `vpython-jupyter` |
| 6 | ++ The JupyterLab extension called `vpython` |
| 7 | + |
| 8 | +## Releasing the Python package |
| 9 | + |
| 10 | +Versions for the Python package are generated using |
| 11 | +[`versioneer`](https://github.com/warner/python-versioneer). That means that |
| 12 | +to make a new release the first step is to generate a git tag with the release |
| 13 | +numbers. |
| 14 | + |
| 15 | +Release numbers should be in the format `X.Y.Z`, e.g. `7.4.2` or `7.5.0`. |
| 16 | + |
| 17 | +Currently, all of the build/upload of the releases is handled on Travis-CI and |
| 18 | +Appveyor, but in principle one could build the packages on local machines and |
| 19 | +upload them. |
| 20 | + |
| 21 | +Tagging the commit in GitHub or doing the tag locally and pushing it to GitHub |
| 22 | +will trigger the builds without any further action. |
| 23 | + |
| 24 | +If you want to build locally: |
| 25 | + |
| 26 | ++ Build and upload the source distribution (once per release) |
| 27 | + * `python setup.py sdist` -- generate the source distribution |
| 28 | + * `twine upload dist/*.tar.gz` -- upload the generated distribution |
| 29 | ++ Build and upload binary wheels (once per release *per platform*) |
| 30 | + * `python setup.py wheel` -- generate binary distribution on the platform |
| 31 | + on which you are running. |
| 32 | + * `twine upload dist/*.whl` -- upload the generated distribution |
| 33 | ++ Build the conda package (once per release *per platform*) |
| 34 | + * `conda build vpython.recipe` |
| 35 | + * `anaconda upload `*recipe_location* -- replace *recipe_location* with |
| 36 | + the directory output by conda build. |
| 37 | + |
| 38 | +## Releasing the JupyterLab Extension |
| 39 | + |
| 40 | +Please see the instructions in the `labextension` folder for building and |
| 41 | +releasing the JupyterLab extension. |
0 commit comments