Request for 1.0.0 (not 0.8.0) as the next non-bugfix release
consideRatio opened this issue · 7 comments
I've took to heart a recommendation from https://semver.org suggesting one should quickly arrive at 1.0.0. Here is excerpt from the section of How do I know when to release 1.0.0?.
If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0.
What do you think about cutting 1.0.0 instead of 0.8.0 when something beyond a bugfix is made, or possibly instead of 0.7.3 as well with a very undramatic release with the purpose of just arriving to 1.0.0 to help communicate about future versions?
Further reasoning
I've grown very fond of both maintaining packages and being a user of packages maintained with a major version released. Like that as a maintainer, communication to users becomes easier just by the version choice.
This project is already helping communicate about changes via a CHANGELOG.md etc, and its also not a new project, so I think it makes perfect sense to make it 1.0.0.
I arrive here now as I saw a pinning in the jupyterhub/the-littlest-jupyterhub distribution of jupyterhub involving this:
nbgitpuller==1.*
jupyter-resource-usage==0.6.*
We want to pin to the major version, but for jupyter-resource-usage we pin to the first version identifier instead as we can't expect there isn't any breaking changes between 0.6 and 0.7. Of course, 0.7 may simply have been a feature rich release that motivated a version bump from 0.6 to 0.7, and not something associated with breaking changes.
Thanks @consideRatio for raising this 👍
I think it makes sense. Agree that having the extra number is indeed useful for communicating changes.
Probably there is still a bit of uncertainty as to what this extension should expose as its API. But if something major comes up we could also always bump to 2.0.0.
Pinging other recent contributors in case they have an opinion on this: @krassowski @echarles @davidbrochart
I am 👍 on this one.
+1
It would be nice to get the components from jupyterlab-system-monitor in this repo before making the 1.0.0 release: #191
And also make the extension compatible with JupyterLab 4 / Notebook 7.
It would be nice to get the components from
jupyterlab-system-monitorin this repo before making the1.0.0release: #191
#191 was fixed by #202 (thanks @mahendrapaipuri!)
And also make the extension compatible with JupyterLab 4 / Notebook 7.
JupyterLab 4 support was added in #195.
However we should look into the kernel usage panel issue with Notebook 7 which does not show properly: #204. Maybe @echarles or @krassowski know more about this?
Closing as 1.0.0 with support for JupyterLab 4 and Notebook 7 is released: https://github.com/jupyter-server/jupyter-resource-usage/releases/tag/v1.0.0
Many thanks @mahendrapaipuri for helping with the PRs!