mirror of
https://github.com/jupyter/notebook.git
synced 2024-12-15 04:00:34 +08:00
23dd0cbb8b
* Add workflow to automate releases * Tmp: Change to trigger to test the workflow * Add step to generate the changelog * Update changelog command * Tweak changelog * Pass github token to the docker container * Get previous tag for changelog * Fix docker command * wip workflow * debug workflow * Debug tag * Add defaults for bash * Add fetch depth to checkout * Use real tag in GH Action step * Create draft release for testing * Tweak CHANGELOG * More tweaks * Update release instructions * Tweak changelog * Ensure build and release share common test jobs * Upload artifacts to PyPI * Prepare dist/ * Copy the wheel * Update workflow to trigger on tags * Test on TestPyPI * Test API token * Add TODO * skip existing * Switch to tags
97 lines
2.6 KiB
Markdown
97 lines
2.6 KiB
Markdown
# Releasing JupyterLab Classic
|
|
|
|
## Automated releases
|
|
|
|
Releases are automated using GitHub Actions. They are triggered when a new tag is pushed to the remote.
|
|
|
|
To cut a new release, run the following:
|
|
|
|
```bash
|
|
# checkout the main branch
|
|
git checkout main
|
|
|
|
# for a patch release
|
|
jlpm release:patch
|
|
|
|
# for a minor version bump
|
|
jlpm release:bump minor
|
|
|
|
# for a major version bump
|
|
jlpm release:bump major
|
|
|
|
# push to the main branch
|
|
git push origin main --tags
|
|
```
|
|
|
|
We follow a similar bump strategy as in JupyterLab: https://github.com/jupyterlab/jupyterlab/blob/master/RELEASE.md#bump-version
|
|
|
|
The release workflow also creates a GitHub release with the new changes generated with [github-changelog-generator](https://github.com/github-changelog-generator/github-changelog-generator).
|
|
|
|
If you would still like to do the release manually instead, read below.
|
|
|
|
## Making a nanual new release of JupyterLab Classic
|
|
|
|
This process is still a bit manual and consists in running a couple of commands.
|
|
|
|
## Getting a clean environment
|
|
|
|
Creating a new environment can help avoid pushing local changes and any extra tag.
|
|
|
|
```bash
|
|
mamba create -q -y -n jupyterlab-classic-release -c conda-forge twine nodejs jupyter-packaging jupyterlab -y
|
|
conda activate jupyterlab-classic-release
|
|
```
|
|
|
|
Alternatively, the local repository can be cleaned with:
|
|
|
|
```bash
|
|
git clean -fdx
|
|
```
|
|
|
|
## Releasing on PyPI
|
|
|
|
Make sure the `dist/` folder is empty.
|
|
|
|
1. Update [jupyterlab_classic/\_version.py](./jupyterlab_classic/_version.py) with the new version number
|
|
2. Commit the changes
|
|
|
|
- `git add jupyterlab_classic/_version.py`
|
|
- `git commit -m "Release x.y.z"`
|
|
|
|
3. Bump the frontend packages:
|
|
|
|
- `jlpm`
|
|
- `jlpm run lerna version x.y.z --no-push --amend --force-publish`
|
|
|
|
4. Run: `python setup.py sdist bdist_wheel`
|
|
5. Double check the size of the bundles in the `dist/` folder
|
|
6. Test the release by installing the wheel or sdist: `python -m pip install ./dist/jupyterlab_classic-x.y.z-py3-none-any.whl
|
|
7. `export TWINE_USERNAME=mypypi_username`
|
|
8. `twine upload dist/*`
|
|
|
|
## Releasing on conda-forge
|
|
|
|
The simplest is to wait for the bot to automatically open the PR.
|
|
|
|
Alternatively, to do the update manually:
|
|
|
|
1. Open a new PR on https://github.com/conda-forge/jupyterlab-classic-feedstock to update the `version` and the `sha256` hash
|
|
2. Wait for the tests
|
|
3. Merge the PR
|
|
|
|
The new version will be available on `conda-forge` soon after.
|
|
|
|
## Publish the packages to npm
|
|
|
|
1. Publish the packages: `jlpm run lerna publish from-package`
|
|
|
|
## Committing and tagging
|
|
|
|
Push the release commit to the `main` branch:
|
|
|
|
```bash
|
|
git push origin main
|
|
```
|
|
|
|
Then create a new release from the GitHub interface.
|