Support JupyterLab 3 (and 2?)

[bollwyvl]

Over on #16 we discussed getting the feature updates landed and then moving forward on supporting JupyterLab 3.

Prior art

Much of the packaging plumbing is visible on a self-PR. It could drop the monaco stuff, as it adds a fair amount of complexity, but much of the other stuff is fine (more aggressive linting/compiler options).

Alternatives

• maintain two branches
  • start a new 3.x branch for JupyterLab 3
    • accept features and bugfixe PRs here
  • start a new 2.x branch for JupyterLab 2
    • accept bugfix PRs here
• somehow support releasing for both from one codebase

Challenges

While the single branch plan sounds like the "happy path," I am concerned about:

• testing
  • would need tox/nox (or a lot of complexity) locally
• features
  • inability to take advantage of newer features on Lab 3.x that aren't backported to 2.x as they emerge
    • maybe identity, settings
• documentation complexity
  • pip install and link to for JupyterLab 2.x see the 2.x branch vs
  • pip install but if you're on JupyterLab 3, then do these five things...

[fcollonval]

Alternatives

* maintain two branches
  
  * start a new 3.x branch for JupyterLab 3
    
    * accept features and bugfixe PRs here
  * start a new 2.x branch for JupyterLab 2
    
    * accept bugfix PRs here

In @jupyterlab/git, we use two branches and meeseeksdev bot backport action (see example). It is usually easier to backport all PR (that are backward compatible). Anyway, I'm happy to take the backport burden.

* somehow support releasing for both from one codebase

In @jupyterlab/git, release are down as GitHub action on release creation event. This make it easy to publish but requires to add secrets (I don't have enough right on this project).

Challenges

For small projects, I prefer the two branches approaches with version specific elements living separately. This allow the latest version to move forward if time does not permit to align features/bug fixes; people interested by the backport can jump any time to help reduce the gap if needed.

[bollwyvl]

we use two branches

great, since these fates of these two should be intertwined, that makes a lot of sense.

GitHub action on release creation event.

Yeah, I feel like this is usually not worth the automation. I'm a big fan, however, of doing a single CI build of release artifacts, and only testing against them, rather than in-tree code, and making them available in a single release bundle. Then moving it up to github, pip, npm, whatever, isn't really that hard, as these things are good at handling tarballs :P

move forward

Well: perhaps a GitHub project makes sense? We've got a a fair number of issues, but some form of prioritization/roadmap would be helpful. Once there's a list of bite-sized things to tackle in a reasonable order, we can split up the work more effectively without as much timezone fatigue.

[fcollonval]

Yeah, I feel like this is usually not worth the automation. I'm a big fan, however, of doing a single CI build of release artifacts, and only testing against them, rather than in-tree code, and making them available in a single release bundle. Then moving it up to github, pip, npm, whatever, isn't really that hard, as these things are good at handling tarballs :P

This is a good practice indeed. Let's do it like that.

Well: perhaps a GitHub project makes sense? We've got a a fair number of issues, but some form of prioritization/roadmap would be helpful. Once there's a list of bite-sized things to tackle in a reasonable order, we can split up the work more effectively without as much timezone fatigue.

A project may make sense indeed to clarify what to do in which order. Could you please start it? I don't have access to the settings of the project.

[bollwyvl]

Project is set up:
https://github.com/jupyterlab/pull-requests/projects/1?add_cards_query=is%3Aopen

To Do is not in any particular order, beyond my personal feeling that schema and some some flavor of frontend testing are important to landing additional features.

Will hoist some of the stuff discussed here (e.g. release engineering).

[fcollonval]

Thanks a lot @bollwyvl

[bollwyvl]

Ok, I think all the work is done now with the two branches, and the up-front docs in the README!