-
Notifications
You must be signed in to change notification settings - Fork 148
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
Comments
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 |
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).
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 In the case of the |
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 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 |
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. |
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
The text was updated successfully, but these errors were encountered: