Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adopt the Jupyter Releaser #691

Open
jtpio opened this issue Oct 12, 2021 · 5 comments
Open

Adopt the Jupyter Releaser #691

jtpio opened this issue Oct 12, 2021 · 5 comments

Comments

@jtpio
Copy link
Member

jtpio commented Oct 12, 2021

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

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

@krassowski
Copy link
Member

krassowski commented Oct 12, 2021

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.

@jtpio
Copy link
Member Author

jtpio commented Oct 12, 2021

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): jupyter-server/jupyter_releaser#176

@krassowski
Copy link
Member

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.

@krassowski
Copy link
Member

I had another shot at it this week and opened jupyter-server/jupyter_releaser#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.

@jtpio
Copy link
Member Author

jtpio commented Nov 1, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants