the-littlest-jupyterhub
the-littlest-jupyterhub copied to clipboard
Document upgrade strategy
People should be able to upgrade 1 minor version of TLJH installations.
- [ ] Decide on & document our upgrade strategy
- [ ] Document various components & how they would react to upgrades
- [ ] Write upgrade documentation
- [ ] Document what to do if we want a 'wipe everything and start over, but preserve user data' upgrade
Related
- #724
- #204
I think the general upgrade strategy is to run the installer again, and that 'ensures' everything to where it should be. This means we need a way in the installer to:
- Tell what the current version is
- Refuse to upgrade if it is unsupported
- Upgrade various components as atomically as possible
- Always have option of 'blow everything away and re-install it' without losing any user state.
Plan is to include this in v0.2, since we don't necessarily want to "freeze" an upgrade pathway yet until we see more usecases out of TLJH.
If anything, I would love to have my installation backed up so that if an upgrade borks it, we can always restore it to the latest working state. (It could be automated or part of the documented upgrade process).
In the requirements-user-env-extras.txt file, it is clearly written that TLJH won't upgrade those libraries if TLJH is upgraded. The documentation should explain why it won't be upgraded (as users can upgrade/downgrade them). I think it would be reasonable in the upgrade documentation to have a table with the versions of the TLJH against the recommended versions of the libraries in the user
env.
(EDIT: https://github.com/jupyterhub/the-littlest-jupyterhub/pull/888/files?short_path=3bd14d0#diff-3bd14d078188074c410028847113ceae68865d0ad5b844a27183ef87fbe2fcc3 seems to already include a table with the user env version upgrade)