3.0 Release Plan

[jasongrout]

Timeline

We released JupyterLab 3.0 on 24 Dec 2020. The changelog is in the documentation.

Major features

We want major features in 3.0 to entice users to upgrade.

• [@blink1073, @jasongrout] Extension system rework, allowing extensions to be installed without rebuilding JupyterLab: Extension Development Wishlist #7468 Project Board
• [@blink1073, @goanpeca, @afshin] Internationalization: Internationalization and localization #3965 PR: Localize strings in JLab #8800 (PR)
• [@Zsailer, @blink1073, @echarles] Jupyter server is the underlying server implementation: JupyterLab as Server Extension #7416
  • The changelog entry for this should highlight that it should be a dropin replacement with some deprecation warnings, and to please report otherwise.
• [@Zsailer, @blink1073] JupyterHub integration - need to bring back labhubapp: Doc change of labhubapp back to jupyterhub-singleuser #8356. Bring back the labhub entry point #8704 Reinstate the labhubapp #8806 (PR)
• [@marthacryan, @ajbozarth] Table of Contents extension: Merge ToC Extension into core #8538
• [@ellisonbg, @afshin ] Single document mode enhancements: Proposal: master plan for single document mode #8567 Improved URL scheme, state, interactions for single document mode #8715 (PR)
• [@afshin, @jtpio] Put debugger in core: Add JupyterLab debugger to core #8747
• [@echarles] Replace usage of insensitive terms : Replace usage of insensitive terms #8533
• [@blink1073] Use json5 for settings Change JSON5 payload to JSON payload #8225

Some other possibilities included (deferred):

• Remove content factory pattern: Remove content factory pattern #8266
• Accessibility: Accessibility Enhancements lumino#81, Accessibility audit #911
• UI refresh (for example, reimagining how notebook tools are accessed in a notebook document)

Known Breaking API Changes

• The semantics of dynamic extensions will be different from regular extensions
• Url semantics will change due to single document mode
• Upgrade from TS 3.7 -> 3.9 affects typing APIs
• Many APIs take an optional ITranslator object

Checklist

Beta

• Update extension guide to use module federation
• Update dependencies in various package.json files and refresh the yarn.lock to pull in latest versions

Release checklist

• Document in changelog that the property inspector moved to the right sidebar. I spent a long time looking for it, and trying to figure out why it wasn't activating in the code, before I discovered that it's on the right sidebar now.

• Release jupyterlab_server 2.0 final

• Blog Post: https://blog.jupyter.org/jupyterlab-3-0-is-out-4f58385e25bb

• Modify and run python scripts/milestone_check.py to check the issues assigned to this milestone

• Write release highlights, starting with:

  loghub jupyterlab/jupyterlab -m XXX -t $GITHUB_TOKEN --template scripts/release_template.txt

• Test the release candidate in a clean environment

• Make sure the CI builds pass

  • The build will fail if we publish a new package because by default it is
    private. Use npm access public @jupyterlab/<name> to make it public.
  • The build will fail if we forget to include style/ in the files:
    of a package (it will fail on the jupyter lab build command because
    webpack cannot find the referenced styles to import.

• Update the other repos:

  • https://github.com/jupyterlab/extension-cookiecutter-js (this should be compatible with jlab 3 as-is, but we should also move it to a prebuilt extension) - Switch to the new extension distribution system extension-cookiecutter-js#33
  • https://github.com/jupyterlab/extension-cookiecutter-ts
  • https://github.com/jupyterlab/mimerender-cookiecutter - this repo was archived. Are we not updating it anymore?
  • https://github.com/jupyterlab/mimerender-cookiecutter-ts
  • https://github.com/jupyterlab/theme-cookiecutter - JupyterLab 3 update theme-cookiecutter#19
  • https://github.com/jupyterlab/jupyter-renderers - Update for JLab 3 jupyter-renderers#233

• Add a tag to ts cookiecutter with the new JupyterLab version

• Update the extension examples:

  • Merge 3.0 -> master: Merge 3.0 -> master extension-examples#137
  • Notebook toolbar button

• Update the extension tutorial

• At this point, there may have been some more commits merged. Run python scripts/milestone_check.py to check the issues assigned to this milestone one more time. Update changelog if necessary.

Now do the actual final release:

• Run jlpm run bumpversion release to switch to final release

• Push the commit and tags to master

• Run npm run publish:all to publish the packages

• Create a branch for the release and push to GitHub

• Update the API docs

• Set the default branch of the APOD repo.

• Publish to conda-forge.

After a few days (to allow for possible patch releases), set up development for
the next release:

• Run jlpm run bumpversion minor to bump to alpha for the next alpha release
• Put the commit and tags to master
• Run npm run publish:all to publish the packages
• Release the other repos as appropriate
• Update version for binder
  • JupyterLab 3.0 Strategy: JupyterLab 3.0 strategy jupyterhub/repo2docker#935
  • PR: Update to JupyterLab 3.0 jupyterhub/repo2docker#996

[jasongrout]

In our meeting, we also decided to not have a 2.1 release since the schedule is pretty tight already with 3.0. I moved all 2.1 milestone issues to the 3.0 milestone.

[saulshanabrook]

I would like to help make a 2.1.0 release happen, so we don't have to wait on 3.0.0 for non breaking changes to be published. I can be the point person for that release if that is useful.

Do we have timelines nailed down between pre-release releases and the final release?

A schedule could be:

1. Release a 2.1.0 prerelease next wednesday.
2. Release 2.1.0 final a week after that.

[jasongrout]

First of all, thank you!

We have 66 open PRs. I'm sure some of them are like your PR that we merged, in that they are backwards compatible and could go into a 2.1. Do you want to take a pass through the PRs to see what else could go in?

I think we haven't merged anything into master that is backwards incompatible. According to the timeline above, we should branch off a 2.x branch now, but unless someone wants to merge a backwards incompatible PR in the next week or two, it makes sense to branch after 2.1, then.

[jasongrout]

@saulshanabrook - I added back a 2.1 milestone and have been assigning a few PRs there for consideration.

[saulshanabrook]

Thanks @jasongrout! I am working on getting some time for this.

[saulshanabrook]

I added back a 2.1 milestone and have been assigning a few PRs there for consideration.

I also just went through and added milestones to most of the recent PRs. I will go through the existing PRs tagged with 2.1 and see what the next step is.

[blink1073]

Thanks @saulshanabrook! I added two issues to the list and assigned them to myself. I should have the two PRs done by the end of the weekend.

[saulshanabrook]

FYI I opened #8084 for the next release.

[jasongrout]

@AlbertHilb - was there a reason to unpin this issue that I missed somewhere?

[AlbertHilb]

@jasongrout - It has been unintentional. I'm so sorry! 😢

[jasongrout]

No problem! I just wanted to make sure I didn't miss something.

[jasongrout]

There is some more conversation about this on gitter. In particular, Saul summarized some of the current thinking here and here

[blink1073]

Given that 19 June is a week away, and we are not where we need to be, I propose the following between now and next meeting:

• Make sure all planned major features are covered in this issue and are linked to other issues
• Define a new schedule at the next meeting
• Do a triage pass in the meeting

[blink1073]

We had some discussion at today's meeting about slipping the release cycle, but have not yet reached a consensus. We will be slipping at least a month, but are waiting for a forthcoming update on the JupyterCON schedule to set a final date.

[saulshanabrook]

@marthacryan released the 3.0.0-alpha0!

[afshin]

@falconair The debugger front-end in JupyterLab is agnostic about what kernel to debug, but the kernel needs to support the debugging protocol. Currently, the xeus-python kernel is the only Python 3 kernel that Jupyter has released which supports debugging. In the future, other kernels will support it as well.

[falconair]

@falconair The debugger front-end in JupyterLab is agnostic about what kernel to debug, but the kernel needs to support the debugging protocol. Currently, the xeus-python kernel is the only Python 3 kernel that Jupyter has released which supports debugging. In the future, other kernels will support it as well.

I see! I misunderstood then, thought a default installation of JL 3 was going to enable full debugging by default. I just installed xeus and am able to debug.

However, it seems magics don't work with the xeus kernel yet. I tried the built-in pycat as well as a magic command I wrote for my class, neither works.

Am I correct in assuming xeus is not quite ready for production yet?

[afshin]

Depending on your use case, xeus-python may or may not be ready for your needs. Here is some information about the current state of the xeus-python kernel: https://github.com/jupyter-xeus/xeus-python/#what-are-the-advantages-of-using-xeus-python-over-ipykernel-ipython-kernel

[falconair]

Depending on your use case, xeus-python may or may not be ready for your needs. Here is some information about the current state of the xeus-python kernel: https://github.com/jupyter-xeus/xeus-python/#what-are-the-advantages-of-using-xeus-python-over-ipykernel-ipython-kernel

Looks like I won't be able to recommend xeus-python to my students yet, since they will expect standard functionality (such as standard magics), which doesn't yet exist.

Thanks to everyone for your help in helping me clear up so many misunderstandings.

As my parting thought: the jupyter ecosystem is immensely useful and the people working on it are providing a great service. On top of that, as witnessed in my exchange here (as well as on discourse), community members are extremely helpful and responsive. However, as a practitioner (and many of my colleagues would agree), there isn't a clear sense of where the jupyter ecosystem stands and where it is going. Until a few weeks ago, I wasn't sure if Jupyter Notebook was considered deprecated in favor of Jupyter Lab or if Lab was still considered an alpha level product. I read the original debugger blog post months ago, but couldn't figure out its status. Similarly with the xeus kernel, until just now, I had no idea where it stood in terms of an experiment vs being production ready. Jupyter Lab 3.0 was released, but I wasn't able to find any mention of it on social media. Even Jupyter's own twitter feed doesn't say anything! I only know because I have been waiting to use the debugger in my classes and have been asking around on discourse. Before I asked my question, even this ticket didn't have a release date.

Way back in my Java developer days, every incremental release of Eclipse would come with a 'New and Noteworthy' post, giving details about where the project was and where it was heading (and we would read it excitedly). End-user developers generally had a good sense of where the ecosystem stood. This is obviously a marketing problem, rather than a technical one so I don't have any solutions. Just an observation that Jupyter lacks in the 'communication' department.

[afshin]

@falconair You raise good points that are not fully addressed by this: but it's worth noting that we haven't published a blog post or social media updates about JupyterLab 3 yet because it was only just released and we wanted to wait until the beginning of a work week to publish social media about it.

As far as the state of where Jupyter's products are headed, we could certainly improve. A big part of our efforts in 2020 have been around how we structure the project and the responsibilities each team has and the role of the umbrella organization itself. These are ongoing conversations.

[meeseeksmachine]

This issue has been mentioned on Jupyter Community Forum. There might be relevant details there:

https://discourse.jupyter.org/t/kernel-messaging-variable-insprector-for-jupyterlab-3-0/7340/4

[jasongrout]

How about we fix the issues listed in the 3.0 milestone, release 3.0.1 with the updated documentation tomorrow, then publish the blog post tomorrow? And include a paragraph in the blog post cautioning that lots of extensions still need to be updated, so be patient.

[jasongrout]

I've released 3.0.1 on pypi, and conda-forge will follow soon with their auto-update bot.

And include a paragraph in the blog post cautioning that lots of extensions still need to be updated, so be patient.

Done (and I added a few more links in the post to relevant docs).

I think we're basically ready to publish the blog post, after

• conda-forge is updated
• after the 3.0.1 docs build.

[jasongrout]

The blog post is now published: https://blog.jupyter.org/jupyterlab-3-0-is-out-4f58385e25bb

[jtpio]

Draft PR to update repo2docker to use JupyterLab 3.0 by default: jupyterhub/repo2docker#996

[jtpio]

Looks like https://github.com/jupyterlab/extension-cookiecutter-ts should be up-to-date now, or was there a couple of items left to address?

[jasongrout]

Looks like https://github.com/jupyterlab/extension-cookiecutter-ts should be up-to-date now

I think you are right.

[Tayflo]

The blog post is now published: https://blog.jupyter.org/jupyterlab-3-0-is-out-4f58385e25bb

Hi, thanks for the work done around! I'm brand new to JupyterLab, and I was looking for Table of Contents functionality (which is great!), so I was very excited to upgrade to v3 (I just re-installed Anaconda and the default JupyterLab is v2).

Using Anaconda, as stated in the blog post, I tried to update with:

conda install -c conda-forge jupyterlab=3

But "solving environment" was taking ages (to collect package metadata and then conflicts were found and looked up).

So I finally aborted (after at least half an hour) and tried instead a solution stated on stackoverflow:

conda uninstall jupyterlab
conda install -c conda-forge jupyterlab=3

It worked in a few tens of seconds.

Maybe the blog post should be edited adding the uninstall instruction? (I guess those will be more properly handled when v3 will be "fully" released, hence if my comment is irrelevant, sorry for the inconvenience.)

[jasongrout]

Conda is well-known for sometimes taking a long time to solve dependencies. That's unfortunate it is causing issues for you.

JupyterLab v3 is fully released. The remaining things on this issue are about updating various other repos

Maybe the blog post should be edited adding the uninstall instruction

I added a note to the blog post that it may help to uninstall first.

[isabela-pf]

I'd really love to close this issue, so I'm going to update extension-cookiecutter-js and mimerender-cookiecutter-ts to be compatible with 3.0 because I can manage to put in a PR that changes one number. I don't have the knowledge to update them to be prebuilt extensions though, so someone else will have to jump in for that.

Hope this is useful, and let me know if I can help in another way.

[jtpio]

Thanks @isabela-pf.

There is now a PR to update extension-cookicutter-js to use the new distribution system: jupyterlab/extension-cookiecutter-js#33, if you want to try it locally and help iterate on it. Thanks!

[jasongrout]

FYI, readthedocs stable is set to track the 3.x branch, which needs to be updated manually when there is a release to trigger a new readthedocs build for its stable build. I didn't figure out how to get readthedocs to just recognize our release tags.

I just updated the 3.x branch to point to the 3.0.6 release tag. We should probably change this branch name to RTD-stable or something, or even better, get readthedocs to recognize our release tags.

[jasongrout]

I'm not sure why readthedocs points its stable build to the 3.x branch in the repo. Relevant docs at https://docs.readthedocs.io/en/latest/versions.html#versioned-documentation

Possibly we just need to create a stable tag and use that to make things clearer? I wish they had a tag that was namespaced to them (like rtd-stable or something) so you could manage readthedocs builds without forcing its naming conventions on the rest of the repo.

[jtpio]

The repo2docker PR has been merged: jupyterhub/repo2docker#996

So JupyterLab 3.0 is now available by default on Binder 🎉

[jtpio]

Looks like all the checkboxes in this issue have been ticked.

Should the issue be closed?

[blink1073]

w00t! Nice work @jtpio taking us over the finish line!