jupyterlab-lsp
jupyterlab-lsp copied to clipboard
jupyter-lsp
Adopt the Jupyter Releaser
Elevator Pitch
More and more repos are now adopting the Jupyter Releaser as a convenient way to make releases: https://github.com/jupyter-server/jupyter_releaser
- https://github.com/jupyterlab/jupyterlab
- https://github.com/jupyterlab/retrolab
- https://github.com/ipython/ipykernel
- https://github.com/jupyter/jupyter_server
- https://github.com/jupyter/jupyter_client
- https://github.com/jupyterlite/jupyterlite
- https://github.com/voila-dashboards/voila
- ... and more
We should check whether we would like to do the same here.
Motivation
This has a couple of benefits. Mostly about removing toil and repetitive tasks from the release process, which can be fully done with GitHub Action workflows.
Also this progressively streamlines the setup used across Jupyter projects.
More on the docs: https://jupyter-releaser.readthedocs.io/en/latest/background/theory.html#motivation
Design Ideas
We follow the adoption guide: https://jupyter-releaser.readthedocs.io/en/latest/how_to_guides/convert_repo.html
If that makes it easier to maintain, and/or easier for others to contribute, I fully agree! How does the releaser interact with monorepo structure? Now that we have an organization we could easily split the jupyter-lsp into a separate repo if it makes more sense.
If that makes it easier to maintain, and/or easier for others to contribute
Right I think it can make it easier for other folks to help make releases if they would like to, since the tools would be the same (they would feel familiar).
How does the releaser interact with monorepo structure?
It's used to release JupyterLab and RetroLab (and also JupyterLite now) which are all monorepos. The releaser handles Python packages leaving at the top level, and workspaces for the JS packages.
In the case of the jupyterlab-lsp we could keep the structure like it is now. Hopefully this PR will make it easier to handle multiple Python packages in the same repo (those under python_packages for example): https://github.com/jupyter-server/jupyter_releaser/pull/176
Thank you for the link. This still does not solve versioning issue and changelog for two separate packages though. I think that splitting the repository might be useful with that regard.
I had another shot at it this week and opened https://github.com/jupyter-server/jupyter_releaser/issues/199 with my questions and comments. I would appreciate some help (and of course ideally a PR, but I'm realistic with expectations - everyone is busy) here. I was thinking about starting small by only adopting the releaser for jupyterlab-lsp Python and NPM package first, and figuring out what to do with jupyter-lsp (and other JS packages) later.
Nice thanks @krassowski for opening that issue.
Usually the tricky part is to know how to bump the version, especially when there are multiple packages depending (that might depend on each other). We could start by having the "Check Release" workflow run on CI first, and see how to continue from there.