search

jupyterhub / the-littlest-jupyterhub

Simple JupyterHub distribution for 1-100 users on a single server
https://tljh.jupyter.org
BSD 3-Clause "New" or "Revised" License
1.03k stars 339 forks source link

Handling versions and releases #724

Closed consideRatio closed 1 year ago

consideRatio commented 2 years ago

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

manics commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

manics commented 1 year ago

I've tagged 0.2.0

consideRatio commented 1 year ago

@manics wieee!!!

consideRatio commented 1 year ago

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

consideRatio commented 1 year ago

I think this is resolved now :D