Bump top-level version on release

[jtpio]

Attempting to make a release after #95 specifying 1.0.0 as the version spec creates a v0.6.1 draft GitHub Release:

This is likely related to the version specified in the top-level package.json:

jupyterlab-topbar/package.json

Line 3 in fee0500

"version": "0.6.1",

cc @mahendrapaipuri

[mahendrapaipuri]

Hmm! That is strange. I will check it. Cheers for creating the issue!

[jtpio]

Probably it's because the version is then read with the hatch version command, which picks up the version from the top-level package.json.

So maybe we can add the top-level path to python-packages here and that would to the bump automatically:

jupyterlab-topbar/pyproject.toml

Lines 20 to 24 in fee0500

	python-packages = [
	"packages/logout-extension:jupyterlab_logout",
	"packages/topbar-text-extension:jupyterlab_topbar_text",
	"packages/theme-toggler-extension:jupyterlab_theme-toggler",
	]

[mahendrapaipuri]

That could be it. I will do some testing and put up a PR.

[mahendrapaipuri]

I think your suggestion should fix it. Actually, we did include top level package in jupyter-releaser packages. But, we removed it eventually as it will create an unnecessary artifact.

[jtpio]

Ah good catch. If it's not picked up by the releaser when publishing the packages then we could leave it since it should be private.

[mahendrapaipuri]

Do you think it will be ignored when publishing? I have tried to test it on my fork without luck.

[jtpio]

So it does create the wheel and source dist, which are likely going to be published to PyPI automatically:

So maybe we could use a releaser hook to remove them so they are not picked up.

[mahendrapaipuri]

Cheers for testing it. You mean using a hook after-build-python to remove the wheel and source dist of jupyterlab_topbar_extensions*?

I guess we can avoid this whole situation by removing pyproject.toml from top level, right?! If I remember well, we are using it just to pass the jupyter-releaser config. Maybe we can move the config to package.json. Do you think it is better solution?

[jtpio]

Yeah maybe there is a simpler way.

Maybe we can move the config to package.json. Do you think it is better solution?

Yes the releaser config can also be set in the top-level package.json. This would already simplify things.

One thing we need though is a way for the releaser to get the current version of the repo, so it shows up as the release title.

Another approach would be to do something similar to the Lumino repo and create a PR to bump versions, and then use the releaser to perform the release: https://github.com/jupyterlab/lumino.
This would also allow for bumping packages independently.

[mahendrapaipuri]

Cheers for the pointer.

jupyter-releaser is also creating a top level empty npm package. I suppose we need to remove it as well?

Another approach would be to do something similar to the Lumino repo and create a PR to bump versions, and then use the releaser to perform the release: https://github.com/jupyterlab/lumino.
This would also allow for bumping packages independently.

If I look into the jupyter-releaser config of Lumino repo, they are not skipping bump-version step in the release workflow.

But I see your point. So, we bump versions manually in a PR and then run jupyter-releaser workflows by skipping bump-version step. In that case the artifacts will still be generated for the packages that are not bumped and potentially overwrite the existing ones in the PyPI and NPM. Do you think it is not an issue? Or Am I missing something?

[mahendrapaipuri]

jupyter-releaser is also creating a top level empty npm package. I suppose we need to remove it as well?

Ignore this comment. This is not an issue as the top level package is marked as private and it does not generate dist file.