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!
choldgraf
All 37 comments
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.
jph00
on 19 Jun 2019
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
choldgraf
on 19 Jun 2019
@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.
gnestor
on 19 Jun 2019
@gnestor you should double-check that link, unless you are combining the release notes with your wedding checklist ;-)
choldgraf
on 19 Jun 2019
OMG! Updated 👍
gnestor
on 19 Jun 2019
I think this one needs to be solved for 6.0 as well: https://github.com/jupyter/notebook/issues/4304
blink1073
on 19 Jun 2019
My vote is to disable the local HTML file by default and enable it via a setting.
blink1073
on 19 Jun 2019
Other issues related to the file launching: https://github.com/jupyter/notebook/pull/4260#issuecomment-448262695
blink1073
on 19 Jun 2019
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
on 19 Jun 2019
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?
choldgraf
on 20 Jun 2019
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.
gnestor
on 20 Jun 2019
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.
jph00
on 20 Jun 2019
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 (#4701 #4576)
lresende
on 20 Jun 2019
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.
choldgraf
on 20 Jun 2019
I agree with all of the above. I'm on vacation right now but I gave you owner rights @choldgraf, make it so 😉
blink1073
on 21 Jun 2019
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
on 22 Jun 2019
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
lresende
on 22 Jun 2019
@lresende, I gave you write permissions to this repo, can you please verify by updating those issues :wink:?
blink1073
on 24 Jun 2019
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
lresende
on 26 Jun 2019
Did you intend for there to be a 5.8 milestone still open? We could rename that milestone to 6.1
blink1073
on 26 Jun 2019
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 ?
lresende
on 26 Jun 2019
I'd rather just go to 6.0 and create a 6.1 milestone, unless the 5.8 issues are dealbreakers
choldgraf
on 26 Jun 2019
I am doing some basic tests with the 6.0 distros and I am planning to push the 6.0 RC1 this morning
4723
lresende
on 26 Jun 2019
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
on 27 Jun 2019
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?
mpacer
on 27 Jun 2019
We already pinged @gnestor to add myself and @lresende on pypi.
blink1073
on 27 Jun 2019
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
on 27 Jun 2019
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.
mpacer
on 27 Jun 2019
This was on the Jupyterlab gitter.
blink1073
on 27 Jun 2019
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.
Carreau
on 27 Jun 2019
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.
jasongrout
on 27 Jun 2019
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) ?
lresende
on 10 Jul 2019
Either day sounds good to me
blink1073
on 10 Jul 2019
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!
SylvainCorlay
on 15 Jul 2019
Notebook release 6.0.0 available and uploaded to Pypi.
lresende
on 16 Jul 2019
Notebook release 6.0.0 available and uploaded to Pypi.
Awesome ! Thanks !
Carreau
on 16 Jul 2019
thanks so much @lresende for pushing this one out 🎉 🎉 🎉
choldgraf
on 16 Jul 2019
Related issues
fonnesbeck
·
3Comments
arilwan
·
3Comments
harshinielath
·
3Comments
mmngreco
·
3Comments
uolter
·
3Comments
Most helpful comment
Notebook release 6.0.0 available and uploaded to Pypi.