Release consistency with version in package.json

[batpad]

This might be a nit that we should totally ignore -

Currently, we publish the jupyterhub-fancy-profiles python package to PyPi using the version specified in the latest git tag. Currently, the latest version on PyPi is v0.4.0: https://pypi.org/project/jupyterhub-fancy-profiles/0.4.0/

We also have a package.json in the root folder with a version field, that is just static at 1.0.0: https://github.com/2i2c-org/jupyterhub-fancy-profiles/blob/main/package.json#L3

This inconsistency is a little jarring, but I'm also not convinced that duplicating the tagged version in package.json as part of a release process is really the best solution.

I think options I see are:

• Bring the version in package.json to be consistent with the tagged version. This either needs to be done manually before making a release and added to release documentation, or automated some-how with automatically making a commit updating package.json (and pushing to main?) from CI when publishing a new tag. I don't think I like either of these options.
• Do nothing. Let package.json specify a different version - especially since we are publishing a Python package and not an npm package, I think this is okay - ideally, we'd add a comment, but it's JSON so we can't add comments.

Just filing this since I noticed the inconsistency and in case people have strong opinions one way or another - I don't think I have an especially strong opinion here. cc @yuvipanda

I'll wait a day for any strong feelings around handling this version mismatch, then I'll go ahead and release 0.5.0 with the TypeScript updates based on the current release process.

[oliverroick]

Do nothing. Let package.json specify a different version - especially since we are publishing a Python package and not an npm package, I think this is okay - ideally, we'd add a comment, but it's JSON so we can't add comments.

I'm with you on this. Since we're not releasing an NPM package, keeping the version number in line with then Python-package version will have little effect.

Bring the version in package.json to be consistent with the tagged version. This either needs to be done manually before making a release and added to release documentation, or automated some-how with automatically making a commit updating package.json (and pushing to main?) from CI when publishing a new tag. I don't think I like either of these options.

Automating the update seems difficult. Currently the release is triggered when a new tag is pushed. But ideally we'd want to commit the updated NPM-package version first, then tag, so the tag includes the updated package version.

We could use npm version, which updates the package number and creates a tag. So instead of git tag -a v<version-number> in step 2 of the release process we could do npm version minor|major and the push the tag.