Jupyterhub

Latest version: v5.2.1

Safety actively analyzes 710445 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 4 of 7

0.15

Fixes vulnerability [GHSA-cg54-gpgr-4rm6](https://github.com/jupyterhub/systemdspawner/security/advisories/GHSA-cg54-gpgr-4rm6) affecting all previous releases.

- Use EnvironmentFile to pass environment variables to units.

0.14

- define entrypoints for JupyterHub spawner configuration
- Fixes for CentOS 7

0.13

Bug Fixes

- Fix `slice` support by making it a configurable option

0.12

New Features

- Allow setting which **Systemd Slice** users' services should belong to.
This lets admins set policy for all JupyterHub users in one go.
[Thanks to [mariusvniekerk](https://github.com/mariusvniekerk)]

Bug Fixes

- Handle failed units that need reset.
[thanks to [RohitK89](https://github.com/RohitK89)]
- Fix bug in cleaning up services from a previously running
JupyterHub. [thanks to [minrk](https://github.com/minrk)]

0.11

New Features

- **Username templates** let you map jupyterhub usernames to different system usernames. Extremely
useful for prefixing usernames to prevent collisions.

Bug fixes

- Users' home directories now properly read from pwd database, rather than assumed to be under `/home`.
Thanks to [cpainterwakefield](https://github.com/cpainterwakefield) for reporting & suggested PR!

0.10

Breaking changes

- `use_sudo` option is no longer supported. It offered questionable security,
and complicated the code unnecessarily. If 'securely run as normal user with
sudo' is a required feature, we can re-implement it securely later.
- If a path in `readonly_paths` does not exist, spawning user will now fail.

New features

- **Dynamic users** support, creating users as required with their own
persistent homes with systemd's [dynamic users](http://0pointer.net/blog/dynamic-users-with-systemd.html)
feature. Useful for using with tmpnb.
- **Add additional properties** to the user's systemd unit with `unit_extra_properties`.
Thanks to [kfix](https://github.com/kfix) for most of the work!

Bug fixes

- If a user's notebook server service is already running, kill it before
attempting to start a new one. [GitHub Issue](https://github.com/jupyterhub/systemdspawner/issues/7)

Dependency changes

- Python 3.5 is the minimum supported Python version.
- JupyterHub 0.9 is the minimum supported JupyterHub version.
- Tornado 5.0 is the minimum supported Tornado version.


How to make a release

`dockerspawner` is a package available on [PyPI] and [conda-forge].

These are the instructions on how to make a release.

Pre-requisites

- Push rights to this GitHub repository

Steps to make a release

1. Create a PR updating `docs/source/changelog.md` with [github-activity] and
continue when its merged.

Advice on this procedure can be found in [this team compass
issue](https://github.com/jupyterhub/team-compass/issues/563).

2. Checkout main and make sure it is up to date.

shell
git checkout main
git fetch origin main
git reset --hard origin/main


3. Update the version, make commits, and push a git tag with `tbump`.

shell
pip install tbump


`tbump` will ask for confirmation before doing anything.

shell
Example versions to set: 1.0.0, 1.0.0b1
VERSION=
tbump ${VERSION}


Following this, the [CI system] will build and publish a release.

4. Reset the version back to dev, e.g. `1.0.1.dev` after releasing `1.0.0`.

shell
Example version to set: 1.0.1.dev
NEXT_VERSION=
tbump --no-tag ${NEXT_VERSION}.dev


5. Following the release to PyPI, an automated PR should arrive within 24 hours
to [conda-forge/dockerspawner-feedstock] with instructions on releasing to
conda-forge. You are welcome to volunteer doing this, but aren't required as
part of making this release to PyPI.

[github-activity]: https://github.com/executablebooks/github-activity
[pypi]: https://pypi.org/project/dockerspawner/
[conda-forge]: https://anaconda.org/conda-forge/dockerspawner
[conda-forge/dockerspawner-feedstock]: https://github.com/conda-forge/dockerspawner-feedstock
[ci system]: https://github.com/jupyterhub/dockerspawner/actions/workflows/release.yaml


How to make a release

`batchspawner` is a package available on [PyPI] and on [conda-forge].

These are the instructions on how to make a release.

Pre-requisites

- Push rights to this GitHub repository

Steps to make a release

1. Create a PR updating `CHANGELOG.md` with [github-activity] and continue when
its merged.

Advice on this procedure can be found in [this team compass
issue](https://github.com/jupyterhub/team-compass/issues/563).

2. Checkout main and make sure it is up to date.

shell
git checkout main
git fetch origin main
git reset --hard origin/main


3. Update the version, make commits, and push a git tag with `tbump`.

shell
pip install tbump


`tbump` will ask for confirmation before doing anything.

shell
Example versions to set: 1.0.0, 1.0.0b1
VERSION=
tbump ${VERSION}


Following this, the [CI system] will build and publish a release.

4. Reset the version back to dev, e.g. `1.0.1.dev` after releasing `1.0.0`.

shell
Example version to set: 1.0.1.dev
NEXT_VERSION=
tbump --no-tag ${NEXT_VERSION}.dev


5. Following the release to PyPI, an automated PR should arrive within 24 hours
to [conda-forge/batchspawner-feedstock] with instructions on releasing to
conda-forge. You are welcome to volunteer doing this, but aren't required as
part of making this release to PyPI.

[github-activity]: https://github.com/executablebooks/github-activity
[pypi]: https://pypi.org/project/batchspawner/
[ci system]: https://github.com/jupyterhub/batchspawner/actions/workflows/release.yaml
[conda-forge]: https://anaconda.org/conda-forge/batchspawner
[conda-forge/batchspawner-feedstock]: https://github.com/conda-forge/batchspawner-feedstock


Changes in sudospawner

Page 4 of 7

© 2025 Safety CLI Cybersecurity Inc. All Rights Reserved.