Release v6.0

[choldgraf]

In the jupyterlab meeting @blink1073 @lresende and I were chatting about cutting a notebook v6.0 release. It looks like there are only 2 unresolved issues for this release so we are nearly good to go (or already gtg if we want to bump those issues to next release).

Here are the release instructions: https://jupyter-notebook.readthedocs.io/en/stable/development_release.html?highlight=release

Several folks that depend on the Jupyter Notebook have mentioned that it would be useful if a new release were cut so that improvements, bugfixes, etc could make it into the packaged versions that many folks depend on. Can we get a release out soon?

(I'd help with a release, but I don't have merge rights on this repo...see also #4697 which notes that we don't have release instructions that I could find)

cc @jph00 who was asking about this as well, and @gnestor who cut the last few releases!

[jph00]

BTW, since fast.ai is dependent on Jupyter Notebook we're also happy to help in the future on releases, if the process were documented, and we had appropriate permissions.

[choldgraf]

Perhaps if somebody from fast.ai is interested in helping with releases, we can use this as an opportunity to build up some release documentation? happy to help with that

[gnestor]

@choldgraf We have pretty good release documentation: https://jupyter-notebook.readthedocs.io/en/stable/development_release.html?highlight=release

It's not very well-indexed by Google but it can be found by searching ReadTheDocs.

@takluyver and I done most of the notebook releases over the past few years. I'm happy to assist @jph00 and others who are interested in helping.

[choldgraf]

@gnestor you should double-check that link, unless you are combining the release notes with your wedding checklist ;-)

[gnestor]

OMG! Updated 👍

[blink1073]

I think this one needs to be solved for 6.0 as well: #4304

[blink1073]

My vote is to disable the local HTML file by default and enable it via a setting.

[blink1073]

Other issues related to the file launching: #4260 (comment)

[choldgraf]

thanks for the link @gnestor , I'd totally missed that (I was expecting it to be in the CONTRIBUTING.md document or linked in there somewhere, my bad). I added the link to the top comment

[choldgraf]

re: the issues that @blink1073 mentioned, if those will take a decent amount of time for somebody to fix, maybe a minor version bump is in order?

[gnestor]

It looks like we have a 5.8 and 6.0 milestone. I'm fine with doing 2 separate releases but if we can knock out these 3 issues quickly then we can skip 5.8 and go straight to 6. I don't have time to work on these issues this week or next but ping me if you need me to cut a release.

[jph00]

Nothing urgent at our end - fastai v2 will use jupyter notebook for the entire build/test/doc system, but no release planned for at least a month. PS: If you need help testing WSL stuff let me know. I use it all the time.

[lresende]

I am looking into creating the 6.0 release and looking on what's needed before that. One of the issues with looking into milestone is that regular folks (e.g. even me) cannot set that property on an issue or pr.

Couple things I was considering:

• There are at least a few old deprecations on the code, which says it should be cleaned in 6.0. Should we actually remove those before the release (e.g. IPython js variable says it is deprecated since 4.0 and should be removed in 5+, but it seems a few tests are still referencing it)
• There seems to be a lot of new PRs around Accessibility, I believe those can be actually added into a minor release (e.g. 6.0.1) but wanted to ask what others think.
• There are other few PRs that would be good to be merged before 6.0 (Port NB2KG PRs to Gateway #4701 Fix binary message issue when configured for gateway forwarding #4576)

[choldgraf]

Given that the big challenge with this repository is a lack of attention from the community, I'd be a fan of:

• Codifying the release instructions to make sure they're clearer
• Giving more people rights to create releases and manage issues
• Releasing more minor versions and more often
• Save the bigger road block issues for major versions

My reasoning is that there's a tension between "we need to ship a new release quickly" and "we need to get the right features in before the new big release", and releasing more often with minor version bumps lets us bring in the minor improvements etc and allows us to focus major release bumps on the "major" features that warrant a new major version.

[blink1073]

I agree with all of the above. I'm on vacation right now but I gave you owner rights @choldgraf, make it so 😉