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 😉

[lresende]

Just a quick update, I have started putting together some release related PRs (#4708, #4709) and I am working on updating the changelog. I am also investigating why the build has started failing recently (if anyone knows more details here, feel free to chime in).

[lresende]

For the build issues, looks like we need to add issue #4680 and pr #4681 to milestone 6 together with the two PRs above. Anyone with proper access would volunteer to help and update the items to milestone 6? @blink1073 @choldgraf

[blink1073]

@lresende, I gave you write permissions to this repo, can you please verify by updating those issues 😉?

[lresende]

We have a few remaining issues on the 6.0 milestone. I am planning to merge them and create an RC for the 6.0 tomorrow morning, and maybe an official 6.0 release together with jupyterLab around the weekend ? @takluyver @blink1073

[blink1073]

Did you intend for there to be a 5.8 milestone still open? We could rename that milestone to 6.1

[lresende]

The 5.8 milestones has been there for a while and it has a few issues and PRs assigned to it, so a pure renaming to 6.1 might cause some confusion in the future. Would we have a case where we would still have a 5.8 release ? Otherwise would it be better to close/delete it and create a new 6.1 Milestone ?

[choldgraf]

I'd rather just go to 6.0 and create a 6.1 milestone, unless the 5.8 issues are dealbreakers

[lresende]

I am doing some basic tests with the 6.0 distros and I am planning to push the 6.0 RC1 this morning
#4723

[mpacer]

I am so excited that 6.0's launch is happening! Python3-only FTW 🎉 Many thanks all (esp. @lresende for pushing this through)

The reason to keep 5.8 alive is if we plan to do any backport work specific to the 5.x sequence that still supports both Python2 and Python3.

[mpacer]

Also — it looks like the release candidate has not made its way to pypi yet.

https://pypi.org/project/notebook/#history

@Carreau @takluyver If we're moving forward with a 6.0.0rc1 release, could you either twine upload the current 6.0.0rc1 or give me permissions to push to the notebook pypi project?

[blink1073]

We already pinged @gnestor to add myself and @lresende on pypi.

[mpacer]

In that case, @gnestor can you also add me (mpacer) on pypi?

Also, @blink1073 — I didn't see that ping in these messages in what channel did that happen?

[mpacer]

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.

Personally, part of my excitement about getting this release out the door is that the 5.x requirement of py2/3 compatibility was a deterrent to participation. Once we're in a world where python3 only features can make their way into the release cycle in a reasonable amount of time, it gets much more exciting.

[blink1073]

This was on the Jupyterlab gitter.

[Carreau]

All you three are added. In exchange I need 5 minutes of one of you time to test the new github feature to only give triage permission to a user.

[jasongrout]

For the wider audience - we don't usually give release permissions to anyone with 5 minutes to test a github feature :). The specific needs just happened to coincide here.

[lresende]

It's about 2 weeks since we did RC1, and AFAIK, no major issue and not much changes have been added after that. Should we target the official 6.0 release by sometime before the end of the week (e.g. 11 or 12) ?

[blink1073]

Either day sounds good to me

[SylvainCorlay]

It's about 2 weeks since we did RC1, and AFAIK, no major issue and not much changes have been added after that. Should we target the official 6.0 release by sometime before the end of the week (e.g. 11 or 12) ?

+1 on a release now!

[lresende]

Notebook release 6.0.0 available and uploaded to Pypi.

[Carreau]

Notebook release 6.0.0 available and uploaded to Pypi.

Awesome ! Thanks !

[choldgraf]

thanks so much @lresende for pushing this one out 🎉 🎉 🎉