Jupyter Notebook v7: what the pip install actually gives you

What Jupyter Notebook solves, and who the v7 rewrite is for

Jupyter Notebook is a web-based notebook environment for interactive computing. You write code in cells, run a cell, and the output (text, a table, a plot) stays attached to that cell in the same document. The file on disk is a notebook document, and the kernel that executes the code is a separate process, which is what makes the tool language-agnostic: the README describes it as the language-agnostic evolution of IPython notebook, split out of the IPython codebase in 2015 in what the project calls The Big Split.

The audience is anyone who needs code, output and prose in one artefact: data analysis, teaching, exploratory work, reproducible write-ups. The README classifies the intended audience as developers, research and scientific users, and system administrators, which matches the three groups who touch it in practice. The analyst writes the notebook, the researcher reads it, and the administrator runs the server that other people connect to.

Version 7 is a different proposition from earlier releases. The README states it is based on JupyterLab components for the frontend and Jupyter Server for the Python server, and calls this a significant change to the code base. That sentence is the whole adoption decision in miniature: the interface you get is assembled from JupyterLab packages, and the process serving it is Jupyter Server, not the server that shipped inside Notebook v6.

How Notebook v7 is assembled from JupyterLab and Jupyter Server

The dependency list in pyproject.toml shows the split directly. The package named notebook depends on jupyter_server>=2.19.0,<3, jupyterlab>=4.7.0a1,<4.8, jupyterlab_server>=2.28.0,<3 and notebook_shim>=0.2,<0.3. Those upper bounds matter: a Notebook 7 install pins JupyterLab below 4.8, so you cannot float JupyterLab independently and expect the notebook interface to keep working.

notebook_shim is the compatibility layer for server extensions written against the older server API. It is what lets some v6-era server extensions keep loading under v7. The README is explicit that this does not extend to frontend extensions: extensions written for Notebook v5 or Classic Notebook v6 are not compatible with Notebook v7. Server-side compatibility and browser-side compatibility are two different stories, and only the first one has a shim.

The repository layout reflects the same architecture. There is a Python package directory (notebook/) alongside an app/ directory and a packages/ directory, and the root package.json declares a yarn workspace covering app, buildutils and packages/*. The build script chains a utilities build, a library build, a lab-extension build and an app build. In other words, the repository ships both a Python distribution and a set of JavaScript packages, which is why a source install pulls in a frontend build step and not just a Python wheel.

Installing Jupyter Notebook with pip and running your first notebook

The README gives one install command for a local installation, after confirming that pip is installed. It does not pin a version, so this installs the current release from PyPI.

pip install notebook

The Python requirement comes from pyproject.toml, which sets requires-python to >=3.10. If your interpreter is older, pip will refuse the install rather than fall back to an earlier line.

Launch the server with the command the README gives:

jupyter notebook

The console prints a local URL with a token, and your browser opens the notebook dashboard. From there you create a new notebook, which starts a kernel and gives you an empty cell. Running the cell sends the source to the kernel and returns the output into the document.

The entry point is declared in pyproject.toml as jupyter-notebook = "notebook.app:main", so the command maps to the notebook.app module. The README points to the Jupyter platform installation documentation on ReadTheDocs for the wider platform, and to the Notebook documentation for advanced usage. For a remote installation the README does not repeat the steps: it says you need some configuration before starting Jupyter Notebook remotely and links to the Jupyter Server page on running a public server. Treat that link as required reading before exposing the port, because the README itself gives no configuration keys.

The v6 extension break is the real upgrade cost

The README's own warning is the limitation worth planning around: upgrading to Notebook v7 may require more work if you use custom extensions, because v5 and v6 frontend extensions do not run on v7. A team with a handful of internal extensions is looking at a port, not a version bump.

The project's stated direction is to stop patching around this. The README encourages anyone with an open pull request adding a feature to switch to the Jupyter Server and JupyterLab architecture and distribute the work as a server extension or a JupyterLab prebuilt extension, so the feature is also compatible with Notebook v7. That is a clear signal about where extension effort should go, and it also means the v6 extension ecosystem is not a place to invest.

Classic Notebook v6 is still maintained, but only in a narrow sense. The README says maintenance and security-related issues only are being addressed in the 6.5.x branch, that v6 depends on nbclassic for its HTML, JavaScript and CSS assets, and that new features and continuous improvement are focused on v7. Notebook v5 is not maintained at all, and the README advises all v5 users to upgrade to Classic Notebook v6 as soon as possible. So there are three tiers, not two: unmaintained (v5), security and maintenance only (v6), and feature work (v7).

One more boundary the README draws: Notebook v7 is not a drop-in for someone who wants the old interface frozen. The frontend is JupyterLab components, so the look and interaction model follow that stack.

JupyterLab as the alternative, and what actually differs

The honest alternative is JupyterLab, and it is not a distant one: Notebook v7 depends on jupyterlab>=4.7.0a1,<4.8, and the README describes the frontend as built from JupyterLab components. If you already run JupyterLab 4.7, you have most of the machinery that Notebook v7 uses.

The difference is the interface model. JupyterLab presents a workbench: a file browser, tabs and split panes, terminals, and multiple documents open at once. Notebook keeps the single-document view, one notebook in the browser tab, which is what many teaching and analysis workflows want. That is the trade: Notebook gives you a narrower surface with less to configure, and JupyterLab gives you the wider one for the price of more screen and more concepts.

Choosing between them is mostly about extensions. A JupyterLab prebuilt extension works in the JupyterLab interface; the README's guidance to distribute new features as JupyterLab prebuilt extensions is aimed at exactly that ecosystem. If your tooling is already a set of JupyterLab extensions, running JupyterLab is the shorter path, and installing notebook on top adds a second interface over the same server rather than a second platform.

A second alternative is not a rival at all: nbclassic, which the README names as the source of the HTML, JavaScript and CSS assets for Classic Notebook v6. If you need the v6 interface specifically, that is the branch and the package to look at, not the main release.

Maintenance cadence, release lines and licence terms

The repository is not archived, and the last push was on 2026-09-21. Recent releases listed are v7.6.2 on 2026-08-11, v7.6.1 on 2026-07-22 and v7.7.0a1 on 2026-07-22. The presence of an alpha alongside patch releases on the 7.6 line tells you the project is cutting both stabilisation and next-line work.

The README states the maintenance policy plainly: the two most recently released major versions are maintained, which currently means Classic Notebook v6 and Notebook v7. That policy is the upgrade clock. When a new major version lands, the oldest maintained line drops out of support, and a team still on it inherits the whole migration at once instead of incrementally. The v5 to v6 advice in the README is what that looks like after the fact.

On licensing, the package metadata declares BSD-3-Clause, and the LICENSE file is referenced from pyproject.toml. The README describes a shared copyright model: contributors keep copyright over their contributions, and the source as a whole is the collective copyright of the Jupyter Development Team rather than any single institution. It asks that source files carry a banner naming the Jupyter Development Team and the Modified BSD License. If you redistribute or vendor the code, that banner convention is the project's stated expectation. This is a description of what the repository says, not legal advice; check the LICENSE file and your own obligations.

Editorial conclusion

Adopt Notebook v7 if you are starting fresh or you can rebuild your frontend extensions as JupyterLab prebuilt extensions, and check that your Python is 3.10 or newer before you install. Stay on Classic Notebook v6 only if you depend on extensions that have no v7 port, and accept that v6 receives maintenance and security fixes rather than new features. Before upgrading a shared deployment, verify two things in your own setup: whether any installed extension declares compatibility with Notebook v7, and whether your remote access configuration matches what the Jupyter Server public-server documentation describes.

Frequently asked questions

Official sources

1. jupyter/notebook on GitHub
2. License: BSD-3-Clause
3. Project website
4. README
5. Releases