Add changelog for 1.0.0-beta.1

[consideRatio]

Action points

• Agree on security communication (https://github.com/orgs/jupyterhub/teams/jupyterhubteam/discussions/8)
• Backport documentation (Backporting documentation to RTD #2227)
• Remove deprecation logic and force new config options (action point: merge Remove deprecated logic and emit clear messages #2211)
• Add hub.lifecycle passthrough config and a fix to the schema for singleuser.lifecycleHooks (action point: merge Add hub.lifecycle configuration #2223)
• Resource requests documentation (Document resource requests for core components #2085, action point: merge docs: add documentation about resource requests #2226)
• Finalize this changelog

[manics]

Are we definitely going for 12.0.0 not 1.0.0? I understand the reasoning for that change in lower level components which are often hidden from end-users, but for a top-level distribution if we go straight to 12.0.0 I think we'll need more explanation.

Also worth noting that up until #2165 we were saying Z2JH was still an alpha release, so in that sense we could justify a proper 1.0.0 release.

Edit: Also isn't a 1.0.0 release of a major jupyterhub (and jupyter?) project worth celebrating and promoting? 🎉 😸

[consideRatio]

Haha yes i agree @manics, it is worth celebrating - no matter what but 1.0.0 feels more worthy of a celebration in a way which is also the crux in my mind.

These are my emotional response to the differences:

• less pressure on cutting 12.0.0 than 1.0.0, we dont need to meet all the dreams and wishes we have and get it over with easier
• feels more acceptable/less pressure to cut next major version version for 12.0.0 to 13.0.0 than 1.0.0 to 2.0.0

I'm very open to any choice among 12.0.0 and 1.0.0 but not very open to delaying a release or cutting 0.12.0 instead of a major version.

Thanks for raising this discussion @manics, i'll go ahead and ping @jupyterhub/jupyterhubteam - 12.0.0 vs 1.0.0 ?

(Kubespawner and Dockerspawner went from a shift like this)

[willingc]

I would recommend going with 1.0.0. It doesn't need to be perfect. The 12.0.0 threw me a bit since I was wondering when we did 1 - 11. ☀️

[choldgraf]

I think that as long as we are explicit in how this team defines "1.0.0" then that is the right path forward to avoid confusion. We should document what the decision means (even if we say something like "this isn't a particularly special release other than we are switching to a more standard interpretation of semver, and this 1.0 status doesn't mean we promise long term support or anything" etc. Does that make sense?

[willingc]

Thanks @consideRatio for taking this on.

[willingc]

Great detail on the release note. Thanks @consideRatio

[consideRatio]

Thumb emoji democracy have made it clear - we go for a 1.0.0 release!

Action points and decisions to make

• UPDATE: We wait!
  JupyterLab 3 as default JupyterLab - the default? #776?

  Should we do it for this major release, and if so, what is the practical change required and its consequences? Is it to set singleuser.cmd to jupyter-labhub, and would that work with JupyterLab 2 and 3?

  I wonder if perhaps @manics or @yuvipanda have some suggestions about this, I'm a bit lost in the complexities of:
  jupyter_server, JupyterLab version compatibility, jupyter-labhub as a entrypoint script and availability of it, and consequences of having KubeSpawner.cmd unset in KubeSpawner that stops passing KubeSpawner.default_url information cmd isn't set.

• KubeSpawner delete_forever feature inclusion: add method to delete namespaced PVC in spawner base class kubespawner#475

  • I've already asked Min to look at it and give input regarding if a JupyterHub 1.4.1 release is required or not for the feature to work.
  • A new release of KubeSpawner is made

• Bumping versions of various dependencies in Z2JH: CHP, KubeSpawner, etc.

[choldgraf]

ping @damianavila who I believe also has done some thinking about potential challenges moving to the new Jupyter Server that comes bundled w/ JupyterLab (e.g., we ran into some issues with nbgitpuller)

[manics]

Based on the discussion on #2138 I'm now inclined to not force the switch to JupyterLab as it looks like it's more complex than we anticipated.

How about this less disruptive plan:

• Don't make the breaking switch to JupyterLab or jupyter-server in 1.0.0
• We wait for JupyterHub 2 before making the switch to JupyterLab (and optionally jupyter-server). Since JupyterHub is the core application in Z2JH it's more justifiable to a make a major Z2JH breaking change when updating to JupyterHub 2, especially as it sounds like JupyterHub 2 isn't too far away
  • In addition JupyterHub 2 will allow the singleuser server to be configured through environment variables instead of command line arguments. Although this is breaking in general this makes future changes easier, since if you introduce a new environment variable older applications will just ignore it, compared to adding a new command line argument which is almost always breaking. We can also make other changes to the singleuser server if necessary, (potentially even supporting jupyter-singleuser 1.4 if we wish, in this case we can set an environment variable to indicate JupyterLab should be used, which will be ignored by 1.4 servers).
• Separately we follow-up on @minrk's suggestion of trying to switch the docker-stacks start scripts to an ENTRYPOINT instead of a CMD

Edit: to be clear I'm not saying we definitely should have backwards compatibility, just that it's an option if we choose to.

Edit 2: Dropping the switch to JupyterLab also makes this release considerably easier as it avoids loads of testing, checking for corner cases, getting the community involved to test release candidates. Instead it's pretty much the usual release- a round of updates, plus whatever's required for jupyterhub/kubespawner#475.

[consideRatio]

(UPDATE: Saw @manics updated comment and no longer have the question I stated)

[yuvipanda]

@manics what do you think of just setting defaultUrl: /lab? This will run notebookapp still, so sidestep all the issues around serverapp. I've been running this in production for a while without any issues.

I think moving to ServerApp will cause a bunch of breaking changes that are too subtle to spot, moving to it in another release seems good.

[manics]

When we made the decision to switch to JupyterLab 3 I thought it'd be easy, just set JUPYTER_ENABLE_LAB=1 so docker-stacks images would pick it up, and custom images would just ignore it. It turns out that doesn't work because it's not enabled for JupyterHub in docker-stacks, and even if it was it wouldn't work because Z2JH overrides the command and ignores the startup scripts.

My next thought was to take Z2JH out of the equation and delegate everything to the Docker image, which would make future changes easier to manage. Unfortunately that ran into a whole load of other problems as detailed in #2138. Having been burnt by that I'm now weary of introducing another override of the image defaults (defaultUrl) in case it causes problems for us in future.

My final concern is that we're introducing a breaking change quite late in the release process. JupyterHub 1.4.1 is out which means #2138 can be released, so I think we're pretty much ready to release Z2JH, and the current list of breaking changes doesn't look too major compared to switching to JupyterLab 3.

Having said all that I won't block the change to defaultUrl if everyone else is in favour of it 😸

[damianavila]

UPDATE: We wait!

+1 on this one 😉
I do think there is still some time needed for the new server story to consolidate.
I have seen issues with server extensions supporting the new jupyter server but not the old one and cryptic failures when you have started the legacy server and your extension no longer work.

[yuvipanda]

I'm happy to wait too :)

[consideRatio]

The "UPDATE: we wait" was written before @yuvipanda suggested that just modifying to a /lab in singleuser.defaultUrl could be reasonable.

I'd love for someone to make the call with regards to that because I'm a bit lost about the implications. Do we wait with that also? @damianavila did input to wait apply to a suggestion of just setting the defaultUrl to /lab as well, or was it to the more complicated discussion?

I'm very lost now but trying to reach a conclusion - do we wait with ALL kinds of changes related to JupyterLab as default?

[damianavila]

@damianavila did input to wait apply to a suggestion of just setting the defaultUrl to /lab as well, or was it to the more complicated discussion?

@consideRatio, my input was related to using the new server, specifically.
Sorry to not be clear enough about that!

do we wait with ALL kinds of changes related to JupyterLab as default?

I think that is a sensible approach.

Setting up the defaultURL to /lab is less "potentially" problematic if we really want to do that... but I could imagine people seeing Lab as default experience and installing server extensions only compatible with the new jupyter server and somehow they would end up in a broken state because their extensions were not properly loaded.
Maybe, I am being over precautions here... but that usually helps with projects widely used as this one 😉

[manics]

Noticed a couple of typos. Let me know when you want a full review.

[consideRatio]

I marked this as ready for review, as it is read for accepting contributions in any form. I updated a checklist in the original post of what remains in my mind before we can cut a release.

[manics]

I'm worried this CHANGELOG is going to become unreadable other than for the current release, it's length already makes it difficult to scroll through to find older information.

Not a blocker for this release but worth thinking about, e.g. could we archive the changelog for previous major releases into a different file? Or have a table of contents at the top?

[consideRatio]

I'm worried this CHANGELOG is going to become unreadable other than for the current release, it's length already makes it difficult to scroll through to find older information.

I opened #2221 to represent this concern and my suggestion for addressing it concretely.

[manics]

Suggestions for #2231 (feel free to edit)