https://zero-to-jupyterhub.readthedocs.io/ defaults to the latest version (master). This is confusing when it doesn't match the latest ~jupyterhub~ zero-to-jupyterhub release, currently v0.6. Examples:
We need a good story for this. And it is even more complicated because the version of the chart is independent of the version of JupyterHub that you get. As in you can use v0.7 of the chart and get v0.9 of JupyterHub. This happens to a lot of people.
I think the z2jh webpage should show the latest version of the helm chart but make clear to people which version of JupyterHub they will get if they use that. Not RTD expert enough: could we (without a lot of effort) add obvious links to the latest revision of the helm chart that corresponds to the last two or so JupyterHub releases?
@betatim Sorry, I meant the version of the docs doesn't match the released zero-to-jupyterhub helm chart, not the jupyterhub version. In the two issues I linked the posters were using chart parameters that were in the dev chart, not the released one. I've updated the original post.
We need a good story for this. And it is even more complicated because the version of the chart is independent of the version of JupyterHub that you get. As in you can use v0.7 of the chart and get v0.9 of JupyterHub. This happens to a lot of people.
Wouldn't it be easier to just align the Helm chart version with the JupyterHub version? So that v0.9 of the helm chart would contain v0.9 of JupyterHub?
@consideRatio Can you reopen this? This issue is for aligning the version of z2jh docs with the released version of the helm chart, independent of the Jupyter version: https://github.com/jupyterhub/zero-to-jupyterhub-k8s/issues/742#issuecomment-401287673
@consideRatio Can you reopen this? This issue is for aligning the version of z2jh docs with the released version of the helm chart, independent of the Jupyter version: #742 (comment)
Yes sorry about that, I initially misunderstood the issue and forgot to remove the "fixes ..." comment in the commit message.
@rnestler the challenge with pinning them together is that when the version of one bumps, then the version of the other would have to bump too. I guess we could align them for major versions, and let the minor versions move independently. However that seems like we're committing ourselves to a pattern that may prove confusing in the future (e.g. a major new helm chart feature is released and we can only bump from 8.1 to 8.2 because the JupyterHub version hasn't changed)
@minrk @yuvipanda what do you think?
There can be complicates when we change configuration options in master, and someone installs the latest tagged version and doesn't find these parts. I think though that there is too much documentation that is unrelated to the Helm chart configuration options etc that motives us to always have the master version - such as setup on EKS etc, which is unrelated to our Helm chart.
With this, I'll go ahead and close this issue to get closer to <100 open issues! A concrete action point in my mind would be to indicate in the master version how long time it was since the latest release or similar.
Most helpful comment
Yes sorry about that, I initially misunderstood the issue and forgot to remove the "fixes ..." comment in the commit message.