Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Planning for release 4.0 with JupyterHub 5 #3406

Open
3 of 4 tasks
consideRatio opened this issue Apr 23, 2024 · 8 comments
Open
3 of 4 tasks

Planning for release 4.0 with JupyterHub 5 #3406

consideRatio opened this issue Apr 23, 2024 · 8 comments

Comments

@consideRatio
Copy link
Member

consideRatio commented Apr 23, 2024

Wishes before we cut 4.0.0-beta.1

Notes for upgrade guide

KubeSpawner has a breaking change that we should describe for users with a z2jh context with various configurations (Users with NFS home folders for example should be aware for example).

@manics
Copy link
Member

manics commented Apr 23, 2024

I'd like us to write migration docs, similar to what was discussed in jupyterhub/jupyterhub#4787, for 3->4 (and for for 2->3 if I get time for completeness). The changelog has to be concise, whereas an upgrade guide can give more context and focus on what (if anything) is important. It's also a place to highlight breaking changes in subcomponents, at the moment we just refer to the component's changelog but the time saved here ends up being spent on providing support on Discourse.

@johnpmayer
Copy link

johnpmayer commented May 3, 2024

I would love to see a new release of jupyterhub/traefik-proxy, in particular for Redis support. I don't know if this is directly tied to 5.0 though.

EDIT by @consideRatio: note that jupyterhub/traefik-proxy is used by jupyterhub/the-littlest-jupyterhub, but not by jupyterhub/zero-to-jupyterhub-k8s

@consideRatio
Copy link
Member Author

@manics about migration docs - I think its entirely in scope to write migration docs about breaking changes in helm chart config etc, but I'd prefer if we don't write migration docs about for example how to migrate oauthenticator config but instead link out to upstream projects.

Looking at the changelog for v3, its mostly upstream things so adding a migration for v3 would not include much then - and for z2jh v4, we also won't have much. I think it can make sense to add an almost empty migration entry describing that though.

image

What do you think?

@Ph0tonic
Copy link
Contributor

Ph0tonic commented May 6, 2024

I think that it could be great if a major version with the following breaking change was released for KubeSpawner, and then directly incorporated in this major version of z2jh.

@manics
Copy link
Member

manics commented May 7, 2024

I think we should document significant breaking changes in subprojects in the upgrade guide. The subproject changelogs are aimed at developers and admins who are very familiar with JupyterHub, but Z2JH (and TLJH) are higher level. They're aimed at system administrators who may not be as familiar with JupyterHub.

For example, the OAuthenticator change to denying all users by default caught several people out. I'm happy to work on the upgrade docs when I get time.

@consideRatio
Copy link
Member Author

consideRatio commented Jun 12, 2024

Kube scheduler should be bumped to 1.29 as well i think (DONE: Bumped to 1.30, since 1.31 is now out)

@consideRatio consideRatio changed the title Planning for release 4.0 with JupyterHub 5.0 Planning for release 4.0 with JupyterHub 5 Sep 5, 2024
@consideRatio consideRatio pinned this issue Sep 6, 2024
@consideRatio
Copy link
Member Author

4.0.0-beta.1 is now released, and I posted https://discourse.jupyter.org/t/jupyterhub-helm-chart-4-0-0-beta-1-is-out/28828

@benz0li
Copy link
Contributor

benz0li commented Oct 1, 2024

Wish before you release 4.0.0 (App version > 5.1.0?):

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants