Move jupyter-releaser config to package.json #101
Conversation
It removes the need to have pyproject.toml on top level, so it does not create an empty wheel Bump version in package.json to 1.0.0. This will be used in names of artifacts of jupyter-releaser workflows
| @@ -1,6 +1,6 @@ | |||
| { | |||
| "name": "jupyterlab-topbar-extensions", | |||
| "version": "0.6.1", | |||
| "version": "1.0.0", | |||
There was a problem hiding this comment.
I guess we'll still need to update this version?
Looking at the logs of the run for this PR, the title for the release is still 1.0.0 in the check release run:
There was a problem hiding this comment.
As we removed the top level python project, bump version step will not bump the version of top level package.json which is eventually used in release titles. So, we are doing it manually to the version that we will use in the jupyter-releaser which is 1.0.0.
For the next minor version, we will need to manually bump the top level package.json to 1.1.0 so that the release titles will contain 1.1.0. Else, release titles will always have current 0.6.1. Does it make sense?
There was a problem hiding this comment.
Yeah but ideally this version bump should be handled by the releaser.
Otherwise if we need to update this version manually every time then we might as well version all packages manually in a dedicated PR as mentioned in #98 (comment)?
There was a problem hiding this comment.
Yeah but ideally this version bump should be handled by the releaser.
Agree! We can have a hook to do it based on env var RH_VERSION_SPEC.
Otherwise if we need to update this version manually every time then we might as well version all packages manually in a dedicated PR as mentioned in #98 (comment)?
As I said in the comment, the unbumped packages will always be overwritten in the registry, right? If you think that is not going to be an issue, we can bump versions manually in a dedicated PR.
There was a problem hiding this comment.
Sorry @jtpio, I was bit occupied last few days. So, how do we do this? Bump versions manually and skip bump-version step in releaser workflows?
If so, how do we manage the version of the top level package? Make a bump everytime we bump version of atleast one of the packages just to create a unique title in releases?
There was a problem hiding this comment.
Thanks @mahendrapaipuri!
And sorry for the late reply.
I'll try to give this more thoughts to this and to how we can version the packages more easily in the future. For simplicity I might just cut a manual release once so we have the packages available for JupyterLab 4. That would give us more time to properly set up the releaser.
|
FYI @mahendrapaipuri almost everything went well with the release, except the step for publishing the Python packages. I opened two follow-up issues to track that: |
jupyter-releaserconfig in top levelpackage.jsonpyproject.tomland so, wheel and source dist of the top level python package will not be createdpackage.jsonto future version that will be used injupyter-releaserFixes #98