-
Notifications
You must be signed in to change notification settings - Fork 790
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add changelog for 1.0.0-beta.1 #2175
Add changelog for 1.0.0-beta.1 #2175
Conversation
Are we definitely going for 12.0.0 not 1.0.0? I understand the reasoning for that change in lower level components which are often hidden from end-users, but for a top-level distribution if we go straight to 12.0.0 I think we'll need more explanation. Also worth noting that up until #2165 we were saying Z2JH was still an alpha release, so in that sense we could justify a proper 1.0.0 release. Edit: Also isn't a 1.0.0 release of a major jupyterhub (and jupyter?) project worth celebrating and promoting? 🎉 😸 |
Haha yes i agree @manics, it is worth celebrating - no matter what but 1.0.0 feels more worthy of a celebration in a way which is also the crux in my mind. These are my emotional response to the differences:
I'm very open to any choice among 12.0.0 and 1.0.0 but not very open to delaying a release or cutting 0.12.0 instead of a major version. Thanks for raising this discussion @manics, i'll go ahead and ping @jupyterhub/jupyterhubteam - 12.0.0 vs 1.0.0 ? (Kubespawner and Dockerspawner went from a shift like this) |
I would recommend going with 1.0.0. It doesn't need to be perfect. The 12.0.0 threw me a bit since I was wondering when we did 1 - 11. ☀️ |
I think that as long as we are explicit in how this team defines "1.0.0" then that is the right path forward to avoid confusion. We should document what the decision means (even if we say something like "this isn't a particularly special release other than we are switching to a more standard interpretation of semver, and this 1.0 status doesn't mean we promise long term support or anything" etc. Does that make sense? |
Thanks @consideRatio for taking this on. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great detail on the release note. Thanks @consideRatio
Thumb emoji democracy have made it clear - we go for a 1.0.0 release! Action points and decisions to make
|
ping @damianavila who I believe also has done some thinking about potential challenges moving to the new Jupyter Server that comes bundled w/ JupyterLab (e.g., we ran into some issues with nbgitpuller) |
Based on the discussion on #2138 I'm now inclined to not force the switch to JupyterLab as it looks like it's more complex than we anticipated. How about this less disruptive plan:
Edit: to be clear I'm not saying we definitely should have backwards compatibility, just that it's an option if we choose to. Edit 2: Dropping the switch to JupyterLab also makes this release considerably easier as it avoids loads of testing, checking for corner cases, getting the community involved to test release candidates. Instead it's pretty much the usual release- a round of updates, plus whatever's required for jupyterhub/kubespawner#475. |
(UPDATE: Saw @manics updated comment and no longer have the question I stated) |
@manics what do you think of just setting I think moving to ServerApp will cause a bunch of breaking changes that are too subtle to spot, moving to it in another release seems good. |
When we made the decision to switch to JupyterLab 3 I thought it'd be easy, just set My next thought was to take Z2JH out of the equation and delegate everything to the Docker image, which would make future changes easier to manage. Unfortunately that ran into a whole load of other problems as detailed in #2138. Having been burnt by that I'm now weary of introducing another override of the image defaults ( My final concern is that we're introducing a breaking change quite late in the release process. JupyterHub 1.4.1 is out which means #2138 can be released, so I think we're pretty much ready to release Z2JH, and the current list of breaking changes doesn't look too major compared to switching to JupyterLab 3. Having said all that I won't block the change to |
+1 on this one 😉 |
I'm happy to wait too :) |
The "UPDATE: we wait" was written before @yuvipanda suggested that just modifying to a I'd love for someone to make the call with regards to that because I'm a bit lost about the implications. Do we wait with that also? @damianavila did input to wait apply to a suggestion of just setting the defaultUrl to I'm very lost now but trying to reach a conclusion - do we wait with ALL kinds of changes related to JupyterLab as default? |
@consideRatio, my input was related to using the new server, specifically.
I think that is a sensible approach. Setting up the defaultURL to /lab is less "potentially" problematic if we really want to do that... but I could imagine people seeing Lab as default experience and installing server extensions only compatible with the new jupyter server and somehow they would end up in a broken state because their extensions were not properly loaded. |
e42641a
to
89024a1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noticed a couple of typos. Let me know when you want a full review.
I marked this as ready for review, as it is read for accepting contributions in any form. I updated a checklist in the original post of what remains in my mind before we can cut a release. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm worried this CHANGELOG is going to become unreadable other than for the current release, it's length already makes it difficult to scroll through to find older information.
Not a blocker for this release but worth thinking about, e.g. could we archive the changelog for previous major releases into a different file? Or have a table of contents at the top?
I opened #2221 to represent this concern and my suggestion for addressing it concretely. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestions for #2231 (feel free to edit)
Co-authored-by: Carol Willing <carolcode@willingconsulting.com>
Co-authored-by: Simon Li <orpheus+devel@gmail.com>
Co-authored-by: Simon Li <orpheus+devel@gmail.com>
Co-authored-by: Simon Li <orpheus+devel@gmail.com>
2f9252e
to
60f274e
Compare
jupyterhub/zero-to-jupyterhub-k8s#2175 Merge pull request #2175 from consideRatio/pr/12.0.0-release
Action points