New versioning system?
ianhi opened this issue · 15 comments
Would it make any sense to match out versioning to jupyterlab. i.e. a release supporting jupyterlab 4 would have version 4.x
I'm not sure if there's any value in continuing to use minor numbers only. The only major feature that I think is now missing is the ability to also use vim in the document editor. Perhaps after a PR adding that we should bump to a major version.
Thoughts?
If #85 is backwards incompatible with JL 3.x, which I assume it is, I would propose using a new major version number for this release, even without file editor vim mode support. I think it's not uncommon to pin by major version numbers, i.e., <1, however unwise this may be. You could use a beta version number if you don't want to use a full major version number without file editor support.
This extension probably could have been 1.0 a long time ago. If it feels weird to make adding support of JL 4 the "1.0" release, then skipping some numbers and matching the major version number of JL that is being supported makes sense as you said.
No strong opinions on matching lab version or not, but definitely +1 for graduating to 1.0+
Going to 4.0:
pros
- Makes it very easy for users to know what to install
- This extension doesn't really a public API that we need versions to denote
cons
- Not really semantic versioning
- a big jump from
0.17.0 - can't return to 1.0 versions after
I lean towards going to 4.0 for user clarity in installation which I think is important.
@ianhi it seems that version from 0.17.0 are broken:
The reason is that the JavaScript assets are now only package once in the share folder and no more in the python package. So trying to read the package.json file fails.
Should those versions be yanked on pypi?
I opened #99 to fix it.
It's only source installs which are broken and wheels work fine, right? If so - probably no need to yank.
I wonder why is there this issue with packaging. The package followed the template and all release tests passed. Should we add more release tests on source builds?
Ah, I see init was not updated. Thanks!
It's only source installs which are broken and wheels work fine, right? If so - probably no need to yank.
Can confirm that the released wheels are functional. I made sure to test them before releasing. It seems as though issue only occurs when you try to import the python package.
Should we add more release tests on source builds?
It would definitely be good to do that, as our only test is importting the python package, which can fail even when the extension is working :/
Ja this is indeed actually the weird case of a pure frontend extension the method _jupyter_labextension_paths is actually not used; frontend code are loaded if found in the labextension folder - not introspecting the Python package for metadata. So indeed the error was not seen previously and the wheels works.
We only test for import in conda-forge recipe at https://github.com/conda-forge/jupyterlab_vim-feedstock/blob/0b5e6d848fe044d863b2f476839d5362ea27c019/recipe/meta.yaml#L29
I understand that both versioning and the __init__.py issue have been resolved.
I am releasing 4.1.0 with the intent of bumping minor version being that downgrading from this release back to 4.0.x could break settings for users.
Also, I would argue that there is a public API which is:
- the settings schema
- the CSS classes/variables (for themes)
I've been loosely following jupyterlab/jupyterlab#14115, which I understand will be going into JL 4.1. Is that going to require us to rewire a number of shortcut selectors? Do we need a pin on JL <4.1?
That's a good question. I hope not, and we should probably test this extension with the next alpha release of JupyterLab after the PR you linked is merged. If there are any breakages for extensions JupyterLab should aim to mitigate them before final release of JupyterLab 4.1.