Handling versions and releases

[consideRatio]

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

[jtpio]

Thanks @consideRatio for raising this :+1:

This sounds particularly useful especially now that JupyterHub 2.0 is out.

TLJH is still pinned on 1.* for now:

https://github.com/jupyterhub/the-littlest-jupyterhub/blob/ad38fad96afe8096e722279da095a0633b5d2c6b/tljh/installer.py#L124

According to the changelog we can expect a couple of breaking changes: https://jupyterhub.readthedocs.io/en/stable/changelog.html?#id1

Which would affect downstream users and plugins if they just run the installer to upgrade.

Maybe the Jupyter Releaser would be able to help here? https://github.com/jupyter-server/jupyter_releaser

[manics]

Two ideas:

Version the installer URL

Include a version/branch component in the URL to the bootstrap script, e.g.

https://tljh.jupyter.org/v2.1.0/bootstrap.py https://tljh.jupyter.org/v2/bootstrap.py

If we use a similar strategy to that used for our GitHub actions we can tag with a normal semver tag (perhaps using jupyter_releaser) and have the v2 tag/branch automatically updated to the corresponding tag.

Wrapper script that fetches the actual bootstrap script

Keep a single URL but change it to a simpler shell script https://tljh.jupyter.org/install.sh that takes a version parameter and downloads the corresponding bootstrap.py.

[meeseeksmachine]

This issue has been mentioned on Jupyter Community Forum. There might be relevant details there:

https://discourse.jupyter.org/t/when-will-tljh-move-to-jupyterhub-2-0/13482/2

[manics]

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

[manics]

I've tagged 0.2.0

[consideRatio]

@manics wieee!!!

[consideRatio]

For reference, @minrk described upgrade expectations in https://github.com/jupyterhub/the-littlest-jupyterhub/pull/858#issuecomment-1486686645.

[consideRatio]

I think this is resolved now :D