Jupyter Server 2.0 Steps

[Zsailer]

Target date for final release: start of SciPy Conference.

• Create 1.x branch in server.
• Update branch references in 1.x branch from main to 1.x.
• Update readthedocs links in 1.x branch.
• Add branch protection for 1.* branches.

List of Features before release:

• Events in Jupyter Server
• Identity
• Terminals Extension
• Typings Support
• Configurable Kernel Websocket Connection

[SylvainCorlay]

Hey @jupyter-server/jupyter-server-council, a first beta release of JupyterLab 3.5 was published yesterday by @fcollonval, loosening the pin on jupyter-server to allow for jupyter-server 2.0.

We now have a proper Jupyter frontend to test jupyter-server 2.0 with.

[fcollonval]

For interested tester, you will need to use pip:

python -m pip install --pre jupyterlab==3.5.0b0

[ellisonbg]

Hi all, do we have a sense of what is blocking a 2.0 stable release?

[blink1073]

Hi @ellisonbg, Zach and I were just on a call talking about this. Roughly we'd like to make another RC on 28 Nov, targeting 5 Dec for the final release.

The PRs we'd like to see merged for the RC are:

• New configurable/overridable kernel ZMQ+Websocket connection API #1047
• Add more coverage #1069

We'd also like to address

• jupyter-server v2 generates new user for each request when auth is disabled #1033

[ellisonbg]

Thanks for the update!

[kevin-bates]

Today's ports_changed exercise got me thinking we should use 2.0 as a means of introducing a subclass to jupyter_client's KernelManager that the server's MappingKernelManager maintains instances of. (We've touched on this at least once in our server team meetings.)

Since major-release boundaries are the time to introduce this kind of thing, should we introduce ServerKernelManager (official name TBD), even if it doesn't house any attributes or methods? Kernel-based events will likely need or want a kernel manager to fire from. In addition, future HA/DR work will use this KernelManager to drive kernel state persistence with the provisioner, etc. Likewise, the activity tracking stuff was "monkey-patched" onto KernelManager when it should probably have been added to an official subclass as well (although I believe that stuff may move into a "monitor" class (probably derived from today's restarter class).

Existing users that have introduced their own kernel manager subclass will simply not have access to any new functionality we introduce into ServerKernelManager until their class hierarchy is updated but should be properly behaved provided we protect calls to new methods on the subclass.

cc: @Zsailer

[Zsailer]

@kevin-bates and I met this morning to discuss this and he's got a PR in the pipeline 🚀

Adding a ServerKernelManager is a fairly small, low-risk change that I believe (and agree with Kevin) should be in 2.0. It will raise a deprecation working for folks who don't subclass from this new class, but their kernel managers will still work until 3.0.

This would enable us to extend+evolve the kernel manager interface to meet the needs of Jupyter Server; as Kevin mentioned, we do a pretty hacky thing today and monkey-patch server-specific traits, attributes, and methods onto the server's kernel manager at runtime. This new manager would allow us to add these APIs more formally and ensure that subclasses could safely depend on them.

Some work in the pipeline, e.g. events, will benefit greatly from this new class.

[Zsailer]

Hey folks! We're delaying the release until tomorrow while we finalize the release notes and blog post.

In the meantime, you can checkout the draft blog announcement here. Feel free to add comments or additional information if you notice anything missing. Thanks!