jupyterlab-lsp 3.0.0rc0 plan #7
Description
Over on https://github.com/krassowski/jupyterlab-lsp/pull/452 @krassowski, (building on @martinRenou's https://github.com/krassowski/jupyterlab-lsp/pull/402) is soooo close 👌 to having a family of release candidates ready that works with JupyterLab 3 🎉, but we don't want to break peoples' stuff just yet.
Here are some thoughts on how we move forward... I hope to get this done (later) today, but wanted to write down some stuff as I was researching.
rc label
Let's do an rc release, as we've done a few upstream dev releases, and this one is more complicated.
I'm thinking our conda_build_config.yml will be like:
channel_sources:
- conda-forge/label/jupyterlab_rc,conda-forge/label/jupyterlab_server_rc,conda-forge
channel_targets:
- conda-forge jupyter_lsp_rcThis will let us easily adapt to upstreams.
packages
jupyter-lsp will get a 1.0.0rc0 release which replaces notebook with jupyter_server, but is otherwise unchanged.
We'll need a new package, jupyterlab-lsp 3.0.0rc0 to require jupyterlab >=3,<4 and jupyter-lsp >=1.0.0rc0,<2. We'll have to update this when the real 3.0.0 comes out.
Luckily it's also a straight pip build, noarch: python, so no funny stuff there.
I don't know whether we'll want to change the outputs for the extra language server stuff, e.g. jupyterlab-lsp-python, etc. I'm leaning towards not, so we don't have two packages running around, and there's really no relationship between version of jupyterlab and the language servers.
versioning
We'll probably want the "magic" {{ version }} to be the jupyterlab-lsp one, as it gets released more frequently, no reason not to let the bot do some of the heavy lifting.