Planning for release 4.0 with JupyterHub 5

[consideRatio]

Wishes before we cut 4.0.0-beta.1

• KubeSpawner release
  Planning release of v7 kubespawner#850
• LDAPAuthenticator 2 release
  • Release plan for 2.0.0 ldapauthenticator#220
• Oauthenticator 17 release
  Planning next release (v17) oauthenticator#753
• Bump to use python 3.12 up from 3.11 in images
• Bump kube-scheduler binary to v1.30 from v1.28 in the user-scheduler #3493

Notes for changelog

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).

• z2jh changelog/migration notes

  • see a specific migration step in the end of add 'safe' slug scheme #744 (comment)
  • script to look at usernames etc considered in add 'safe' slug scheme #744 (comment) considered

[manics]

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]

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]

@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.

What do you think?

[Ph0tonic]

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.

• add 'safe' slug scheme kubespawner#744

[manics]

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]

Kube scheduler should be bumped to 1.29 as well i think