Handling versions and releases

I’ve grown to think that cutting releases is a way to reduce maintenance workload, rather than increase it. By having releases, one can understand and pinpoint issues a lot easier, and communicate about changes to the end users that can figure out their own issues a lot easier.

I’m thinking it would be good if TLJH started handling releases. Do I have support for this idea if I or someone else would start to work towards that?

The Bootstrap script

We currently have a bootstrap/bootstrap.py script that downloads the default branch from github. I suggest that script is remade to download a given version, which would be the latest if it is unspecified.

We have documented access to this script like…

curl -L https://tljh.jupyter.org/bootstrap.py

So in practice, users can perhaps always be assumed to use the latest version of the script, but we can still add a section in the TLJH changelog about changes to this script over time.

The TLJH Python package

I suggest we version control this as any other Python package.

Related

• About defining an upgrade strategy, but then we need version to relate to: https://github.com/jupyterhub/the-littlest-jupyterhub/issues/81

[manics]

A consequence of not having releases is

root@ubuntu1804:~# /opt/tljh/hub/bin/pip list | grep the-littlest-jupyterhub
the-littlest-jupyterhub          0.1

will always be 0.1.

This makes debugging upgrades quite difficult, e.g. https://github.com/jupyterhub/the-littlest-jupyterhub/issues/762

[manics]

I’ve started work on this in https://github.com/jupyterhub/the-littlest-jupyterhub/pull/819