Jupyterlab: 3.0 Release Plan

[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 https://github.com/jupyterlab/jupyterlab/issues/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! :cry:

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

[blink1073]

Given that the JupyterCON dates have slipped to October 5–17, I propose we push the schedule back by six weeks:

| Week| Approximate Date | Milestone |
| ----------:| ---------- | ------------ |
| 0 | 28 Feb 2020 | Previous release published. Master is not branched to allow for easy patch releases. |
| 2 | 13 Mar 2020 | Previous release is branched. Master now allows breaking changes and is for the next major release. Alpha released every two weeks? |
| 22 | 31 Jul 2020 | API freeze, beta released every week? Bugfixes and features that are backwards compatible allowed. |
| 25 | 31 Aug 2020 | RC, only high priority bugfixes allowed. Collateral updates happen (changelog, our custom extensions, etc.). This is the week of Scipy, so sprints are possible in the weekend to help people to update extensions, etc. |
| 28 | 15 Sep 2020 | Final release published |
| 30 | 30 Sep 2020 | JupyterCon announcement |

[jasongrout]

Given that the JupyterCON dates have slipped to October 5–17, I propose we push the schedule back by six weeks:

Sounds good to me. We certainly have our work cut out for us to get everything done in one month!

[blink1073]

I updated the main comment.

[meeseeksmachine]

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

https://discourse.jupyter.org/t/are-there-speed-up-tricks-hacks-repo2docker-can-use-for-jupyter-lab-extension-installs/5143/4

[blink1073]

I updated the timeline to reflect a week slip

[blink1073]

We are in need of a champion for "replace usage of insensitive terms": #8533 if someone is able to step in.

[echarles]

I hope I can stack time by end of this week for https://github.com/jupyterlab/jupyterlab/issues/8533 (I have worked on the white/black list features, so it should not be difficult for me).

[blink1073]

I pushed the beta to Monday Aug 10th to give us a bit more time to wrap things up, but left the other dates intact

[blink1073]

Pushing beta back to tomorrow Aug 11th to give us a bit more time to wrap up existing PRs.

[lindhe]

I'd love to try this pre-release. Can I already install it via pip? I'm not very familiar with pip, how do I go about selecting 3.0 instead of stable?

[blink1073]

Hi @lindhe, you can install as pip install --pre jupyterlab

[jasongrout]

FYI, we decided in the team meeting yesterday to continue releasing 3.0 release candidates during JupyterCon, and release 3.0 final the week after JupyterCon, i.e., 3.0 final is planned for the week of Oct 19-23, for several reasons:

1. We don't want to disrupt JupyterCon by releasing a new JupyterLab where many extensions have not been ported over yet. Most JupyterCon talks have been recorded at this point, and people installing JupyterLab during the conference will be disrupted if most extensions do not work, or if they have to remember to install JupyterLab 2.x.
2. JupyterCon is a great time to advertise the RC and (a) get feedback about the RC and (b) help extension authors port their extensions over. We can talk about all the cool things coming and demo the RC.
3. As for me, I need to work on JupyterCon and will not have time to finish a 3.0 release. Others could do the release, of course, so this isn't a deciding factor.

[jasongrout]

There are some PRs (#8968, #8970, #8972) targeting notebook performance improvements that are being worked on for an eventual 2.x release (2.3.0?). @echarles has been working hard on these (and others reviewing them) for a while, and we are really grateful for his work.

Since they are targeting the 2.x branch, they aren't going into master (i.e., 3.0) right now. I think it would be confusing to have improvements in 2.3.0 that are not in 3.0 - people will then have to decide between upgrading to 2.3.0 or 3.0, instead of just assuming that if they upgrade to 3.0 they get the latest and best. On the other hand, 3.0 is in the RC phase, and making major changes to how notebooks render may disrupt the 3.0 timeline and people's expectations about it being in the RC phase.

So: presuming the changes in #8968, #8970, and #8972 prove to have good performance benefits and are ready to merge soon, what should our strategy be regarding a 2.3 release and a 3.0 release?

@echarles, as one option, would you be able to port the changes to 3.0 in the next two weeks? Are these three PRs the only ones, or did I miss any more?

CC @echarles @saulshanabrook

[echarles]

There are some PRs (#8968, #8970, #8972) targeting notebook performance improvements that are being worked on for an eventual 2.x release (2.3.0?). @echarles has been working hard on these (and others reviewing them) for a while, and we are really grateful for his work.

Others than myself have worked hard also to brainstom, define the technical implementations, design the UI, review, test with completion, and so on and so one... thx to them.

Since they are targeting the 2.x branch, they aren't going into master (i.e., 3.0) right now. I think it would be confusing to have improvements in 2.3.0 that are not in 3.0 - people will then have to decide between upgrading to 2.3.0 or 3.0, instead of just assuming that if they upgrade to 3.0 they get the latest and best. On the other hand, 3.0 is in the RC phase, and making major changes to how notebooks render may disrupt the 3.0 timeline and people's expectations about it being in the RC phase.

I can put more work on helping the RC so the timeline is relaxed and if useful pull the performance improvements. Please assign me tasks via issues, PR review... or whatever.

So: presuming the changes in #8968, #8970, and #8972 prove to have good performance benefits and are ready to merge soon, what should our strategy be regarding a 2.3 release and a 3.0 release?

We are lucky as we have a client that will devote work (acceptance testing with a team for that) during next week to test those performance changes in a 2.3 to be released. They would report back any issue and I would fix them. We will be able to have full confidence in those improvements by the end of the week.

@echarles, as one option, would you be able to port the changes to 3.0 in the next two weeks? Are these three PRs the only ones, or did I miss any more?

I can begin the port of the performance changes on master begin next week (well, when the 3 PRS will be merged in 2.2.x) and the test reports will ensure we have correct end-user behavior.

[echarles]

There is also the VIM support https://github.com/jupyterlab/jupyterlab/pull/9068 that has been WIP since some time that I would like landing in 3.0. The functionality is now ready and based on the new planning, it may be worth considering that. I will put it at the agenda of this week meeting. If @ianhi feels good with that, he may join to share what he has done, and may even give he demo. @ianhi, we are very welcoming and so happy when we see new names on zoom.

[jasongrout]

Thanks for bringing this up. Some questions I would hope would be addressed in a presentation are:

1. How does this interact with the various vim extensions out there for jlab (see your summary at https://github.com/jupyterlab/jupyterlab/issues/8592#issue-642308132, for example). In the past, we've decided having an extension people could install worked well. What are the reasons to move this into core now?
2. How does this address the issues that we've run into in the past when trying to have vim keyboard mode in the notebook? For example, some very early discussion at https://github.com/jupyterlab/jupyterlab/issues/3885#issuecomment-466533619, or in #1362
3. Probably the most urgent question for me: We're at the RC stage in the release process. I realize there are still probably too many things going in for an RC, but on the other hand, we're not putting in things that make huge changes in how people interact with JupyterLab. I think the biggest UX thing we're still working on is the slider for single-document mode, but that is just exposing a menu item more easily. I really hesitate putting something big in at this point in 3.0. For that reason, my initial reaction is to make this a headline feature for 3.1, which would give the rest of us a lot of time to try it out before its release.
4. Probably the most fundamental question, related to question 1 above: the idea up to this point has been to intentionally keep the notebook keyboard interactions simple and uniform across Jupyter installs as a feature, at least in the default distribution. Including a very different keyboard interaction mode in core jlab would be a departure from this decision. Do we want to do that? I can see arguments for both sides, for example, people really like their vim-style interaction, and there is lots of confusion when people select vim keybindings but only see it affect the editor, etc. On the other hand, it's really nice that stock Jupyter applications all work alike, across jlab and classic notebook.

Anyways, I'm looking forward to discussing this!

[ellisonbg]

Keyboard handling and interactions are some of the most complex parts of JupyterLab. As a result I don't believe we should merge the VIM PR this close to 3.0.

[jasongrout]

Right on schedule, webpack 5 is now released!

[jasongrout]

Upgrade to webpack 5 at #9148

[telamonian]

@ellisonbg I agree that it makes sense to not rush the vim mode into the release. Especially if really do plan on doing the final release next week.

But, as much as I personally loathe the idea of a built-in vim mode, I have to acknowledge that it's easily one of our most requested features. Our users are clamoring for it.

@echarles Will vim mode require any breaking API changes to implement? So if needed, can vim mode be a 3.1 feature?

Also, in regards to the ongoing accessibility work, will the vim mode increase the range of jlab interactions that can be accomplished using only a keyboard?

[echarles]

@telamonian Options for VIM has been discussed during last weekly meeting and my understanding is that 2 minor PR to prepare the VIM work would be targeted for 3.0 (@ianhi is working on it I think). VIM as such will be indeed for 3.1 and I don't see any breaking change that would be needed. Great call for accessibility! A well documented would help to demonstrate the added-value. While playing with VIM mode in notebook, I have been amazed how my keyboard useful could be and my mouse being optional.

@jasongrout For performance, I am still collecting user feedback on the 2.3alpha release. I opened 2 PR to take into account the preliminary feedbacks. If 3.0 is out next week, I don't think we can get performance in. The idea is to have a final 2.3 to be sure that we ship the expected end-user behavior.

[jasongrout]

In my view, the unsolved blockers for 3.0 are:

https://github.com/jupyterlab/jupyterlab/issues/9105
https://github.com/jupyterlab/jupyterlab/issues/9121
https://github.com/jupyterlab/jupyterlab/issues/8804

[ellisonbg]

Have we resolved the narrow left panel issue?

On Tue, Oct 20, 2020 at 5:19 PM Jason Grout [e-mail]
wrote:

In my view, the unsolved blockers for 3.0 are:

9105 https://github.com/jupyterlab/jupyterlab/issues/9105

9121 https://github.com/jupyterlab/jupyterlab/issues/9121

8804 https://github.com/jupyterlab/jupyterlab/issues/8804

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jupyterlab/jupyterlab/issues/8038#issuecomment-713213428,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAGXUA7O6I7HAAY44OYIWDSLYSHXANCNFSM4LGU7SGA
.

--
Brian E. Granger

Principal Technical Program Manager, AWS AI Platform ([email protected])
On Leave - Professor of Physics and Data Science, Cal Poly
@ellisonbg on GitHub

[flying-sheep]

Hi, I wanted to make you aware of a bug that’s also present in 3.0 and might have more far-reching consequences, as it affects a core part of jupyterlab’s model architecture: notebook metadata (IObservableJSON) is broken when accessed from extensions #9183

[meeseeksmachine]

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

https://discourse.jupyter.org/t/jupyter-server-1-0-and-the-new-jupyter-server-github-org/6657/1

[jasongrout]

Running the milestone check script, I got this confusing list:

PRs that are in the milestone, but have no commits in the version range.
These PRs probably belong in a different milestone.

https://github.com/jupyterlab/jupyterlab/pull/8550
https://github.com/jupyterlab/jupyterlab/pull/8422
https://github.com/jupyterlab/jupyterlab/pull/8456
https://github.com/jupyterlab/jupyterlab/pull/8454
https://github.com/jupyterlab/jupyterlab/pull/8551
https://github.com/jupyterlab/jupyterlab/pull/8966
https://github.com/jupyterlab/jupyterlab/pull/9394
https://github.com/jupyterlab/jupyterlab/pull/8531

It turns out that indeed, the merge commits for these PRs is in the 2.2.0 branch. However, around the 2.2.0 release is when 2.2.x was branched from master, and apparently there was an explicit reversion of some PRs in the 2.2.x series, so while the merge commit is in the 2.2.x branch, it was not in the 2.2.x release. These commits in 2.2.x reverted some of these PRs:

• a97c165b15 Revert "Merge pull request #8422 from jasongrout/ts39"
• ae802a8400 Revert "Merge pull request #8454 from jasongrout/lint-errors"
• 4482c2dcaf Revert "Merge pull request #8456 from afshin/mobile"
• ef44c11c5b Revert "Merge pull request #8538 from marthacryan/mergetoc"
• 300116a7c6 Revert "Merge pull request #8531 from ellisonbg/sdm1"

The rest of the PRs I've moved to the corresponding 2.2.x branches.

[jasongrout]

The other thing I noticed is that we got a lot of spurious warnings because (a) GitHub will not give us the full list of commits for several PRs:

WARNING: PR 8747 (merge 5ad8b9ae3909b3cd166ea3a8aa48603bb8365aec) has 1141 commits, but GitHub is only giving us 250 of them
WARNING: PR 8538 (merge 94a622d3f9ac2f8bd6b3a2bfe1933f46c77ed053) has 527 commits, but GitHub is only giving us 50 of them
WARNING: PR 7416 (merge 023cb66eb6b0b9ab0f0aedf97afcc8e4bdb96e5e) has 137 commits, but GitHub is only giving us 0 of them

and (b) our automatic parsing of commits of the form "Merge pull request ..." was getting tripped up by the extra history we picked up when we merged the debugger (we got a new root for that). So I excluded the debugger commits from before the merge from the 3.0 milestone (i.e., before 6507205805): https://github.com/jupyterlab/jupyterlab/blob/12e22df235bd9dabf658846e87b56f2444313416/scripts/milestone_check.py#L27-L28

[krassowski]

@jasongrout what is the status of the release? The top comment says "releasing by 31" (today), but it seems 3.0 was actually released one week ago on PyPI. When I was looking at the punchlist I got a feeling that the release did not happen just yet and then I was surprised to see that it actually did.

[jasongrout]

@jasongrout what is the status of the release?

Thanks, you're right, I should have added an update comment here.

We did release 3.0 on Dec 24 (Merry Christmas everyone! :). Most of the devs have been on holiday for the last week, though, so traffic has been sort of slow. I left this issue open since there are a number of updates for other repos that happen after a release that have not been done due to holidays, and will probably be done in the first few weeks of January.

[falconair]

@jasongrout I just tried to upgrade JL via conda conda update jupyterlab and it looks like it still wants to install 2.2.9:

...
  jupyterlab               pkgs/main::jupyterlab-2.2.6-py_0 --> conda-forge::jupyterlab-2.2.9-py_0
...

(I also noticed that Anaconda, itself, is at version 2020.11)

Any idea when we will be able to install 3.0 with a standard conda installer (my students are not always proficient enough to add dev channels to conda).

[krassowski]

@falconair are you using Python 3.6 by any chance? If yes then there is an open PR to bring it back for py3.6 here: https://github.com/conda-forge/jupyter_server-feedstock/pull/34

[jasongrout]

We maintain the conda-forge and pypi packages. If you are asking about anaconda packages-we don't maintain those or have any control over them. You'll need to talk to Anaconda about them.

[bollwyvl]

Yerp: their recipes are here:

https://github.com/AnacondaRecipes/aggregate

With the lab-specific one here:

https://github.com/AnacondaRecipes/jupyterlab-feedstock

[falconair]

@jasongrout If anaconda doesn't have JL 3 officially, then I'll do the work to get my students to add conda-forge as a channel.

@krassowski , looks like I'm on Python 3.8.5. I installed a fairly recent anaconda instance so it should be the latest (hence Python 3.8).

__btw, I'm happy to take this to a different forum, such as Stack Overflow, if this is not the right place to debug this__

I did try conda install -c conda-forge jupyterlab=3.0.0 and it claims to install JL 3:

(base) C:\Users\shahb>conda install -c conda-forge jupyterlab=3.0.0
Collecting package metadata (current_repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Solving environment: failed with repodata from current_repodata.json, will retry with next repodata source.
Collecting package metadata (repodata.json): done
Solving environment: done

## Package Plan ##

  environment location: C:\Users\shahb\anaconda3

  added / updated specs:
    - jupyterlab=3.0.0


The following packages will be downloaded:

    package                    |            build
    ---------------------------|-----------------
    anyio-2.0.2                |   py38haa244fe_3         111 KB  conda-forge
    ca-certificates-2020.12.5  |       h5b45459_0         173 KB  conda-forge
    certifi-2020.12.5          |   py38haa244fe_0         144 KB  conda-forge
    jupyter_server-1.1.3       |   py38haa244fe_0         330 KB  conda-forge
    jupyterlab-3.0.0           |     pyhd8ed1ab_0         5.6 MB  conda-forge
    jupyterlab-git-0.22.0      |             py_0         247 KB  conda-forge
    jupyterlab_server-2.0.0    |     pyhd8ed1ab_0          36 KB  conda-forge
    nbclassic-0.2.5            |     pyhd8ed1ab_0          17 KB  conda-forge
    openssl-1.1.1i             |       h8ffe710_0         5.8 MB  conda-forge
    sniffio-1.2.0              |   py38haa244fe_0          15 KB  conda-forge
    ------------------------------------------------------------
                                           Total:        12.4 MB

The following NEW packages will be INSTALLED:

  anyio              conda-forge/win-64::anyio-2.0.2-py38haa244fe_3
  jupyter_server     conda-forge/win-64::jupyter_server-1.1.3-py38haa244fe_0
  nbclassic          conda-forge/noarch::nbclassic-0.2.5-pyhd8ed1ab_0
  python_abi         conda-forge/win-64::python_abi-3.8-1_cp38
  sniffio            conda-forge/win-64::sniffio-1.2.0-py38haa244fe_0

The following packages will be UPDATED:

  jupyterlab               pkgs/main::jupyterlab-2.2.6-py_0 --> conda-forge::jupyterlab-3.0.0-pyhd8ed1ab_0
  jupyterlab_server  pkgs/main::jupyterlab_server-1.2.0-py~ --> conda-forge::jupyterlab_server-2.0.0-pyhd8ed1ab_0

The following packages will be SUPERSEDED by a higher-priority channel:

  ca-certificates    pkgs/main::ca-certificates-2020.12.8-~ --> conda-forge::ca-certificates-2020.12.5-h5b45459_0
  certifi            pkgs/main::certifi-2020.12.5-py38haa9~ --> conda-forge::certifi-2020.12.5-py38haa244fe_0
  conda               pkgs/main::conda-4.9.2-py38haa95532_0 --> conda-forge::conda-4.9.2-py38haa244fe_0
  openssl              pkgs/main::openssl-1.1.1i-h2bbff1b_0 --> conda-forge::openssl-1.1.1i-h8ffe710_0

The following packages will be DOWNGRADED:

  jupyterlab-git                        0.23.2-pyhd8ed1ab_0 --> 0.22.0-py_0


Proceed ([y]/n)? y


Downloading and Extracting Packages
ca-certificates-2020 | 173 KB    | ############################################################################ | 100%
sniffio-1.2.0        | 15 KB     | ############################################################################ | 100%
openssl-1.1.1i       | 5.8 MB    | ############################################################################ | 100%
jupyterlab_server-2. | 36 KB     | ############################################################################ | 100%
jupyter_server-1.1.3 | 330 KB    | ############################################################################ | 100%
anyio-2.0.2          | 111 KB    | ############################################################################ | 100%
jupyterlab-git-0.22. | 247 KB    | ############################################################################ | 100%
certifi-2020.12.5    | 144 KB    | ############################################################################ | 100%
nbclassic-0.2.5      | 17 KB     | ############################################################################ | 100%
jupyterlab-3.0.0     | 5.6 MB    | ############################################################################ | 100%
Preparing transaction: done
Verifying transaction: done
Executing transaction: done

After this, I restarted Jupyter Lab via Anaconda Navigator, where it showed JL's version as 3.0.0.

However, I don't see the ability to debug cells, which is the main reason I'm upgrading to 3.0. The 'Launcher' window only shows "Python 3" as a kernel. The 'Change Kernel' menu also doesn't show anything other than Python 3. I'm mentioning this, in case I should see a reference to Xeus.

[krassowski]

Xeus kernel does not ship by default, you need to install it (xeus-python) - have a look at the binder over here: https://gist.github.com/jtpio/8d392846c2f3ee6fab38cdfab5a364ec.

[falconair]

Xeus kernel does not ship by default, you need to install it (xeus-python) - have a look at the binder over here: https://gist.github.com/jtpio/8d392846c2f3ee6fab38cdfab5a364ec.

@krassowski and is xeus-python required for graphically debugging cells? My understanding was that the debugger was now being shipped with 3.0.

[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

• [x] conda-forge is updated
• [x] 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: https://github.com/jupyterhub/repo2docker/pull/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: https://github.com/jupyterlab/extension-cookiecutter-js/pull/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.