Jupyter Server 2.0 Steps

[Zsailer]

Target date for final release: start of SciPy Conference.

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

List of Features before release:

• [x] Events in Jupyter Server
• [x] Identity
• [x] Terminals Extension
• [x] Typings Support

[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:

• #1047
• #1069

We'd also like to address

• #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!

[davidbrochart]

I just left a few comments. Should we talk about jupyter_server_fileid? Even though it's not a required extension of jupyter-server, it is required by JupyterLab 4.0 and 3.6.

[echarles]

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!

Thx for setting this up @Zsailer. My main feedback is about the value for the user which is not highlighted. We can see great technical building block, each of them could be enriched with end-user use-cases.

[echarles]

Worth also mentioning which frontends is intended to rely on jupyter server v2

[Zsailer]

Thanks, all, for the great feedback!

Should we talk about jupyter_server_fileid? Even though it's not a required extension of jupyter-server, it is required by JupyterLab 4.0 and 3.6.

I struggled with this one quite a bit. I definitely think it deserves a place in a Jupyter Server blog post, but felt we should save it for a future blog post, when we tell an awesome story about how this service empowers commenting, ydoc, etc.

My main feedback is about the value for the user which is not highlighted

Thanks @echarles. I tried to add some language to emphasize the benefit for end users. As you mentioned, many of these pieces are more building blocks towards better end-user benefits, so it's difficult to clearly articulate the perks. I hope it's (at least) a little better 😃.

Worth also mentioning which frontends is intended to rely on jupyter server v2

I do mention JupyterLab and Jupyter Notebook in the second line as frontends that use jupyter server 2.0, but I specifically avoided talking about notebook v6, v7, nbclassic, etc. I think this is better suited for a follow up blog-post around the evolution of Jupyter Notebook.

[Zsailer]

Closing this issue, since Jupyter Server 2.0 is released! Congrats all!