Re: [jupyter] Formalizing preparing a release

I am definitely in favor of this. We have millions of users, with many of them organizations, universities, non-profits, researchers, etc. who are relying on our software and building on top of it. So, in addition to our own developers needing to know about and discuss releases, we also have a

Re: [jupyter] Formalizing preparing a release

It would be a good idea to include a tentative release calendar at the bottom of the weekly development update that Matthias has been helpfully sending to this list. Capturing information in a release planning table would be beneficial; it would have been hugely helpful last year for planning

Re: [jupyter] Formalizing preparing a release

I think announcing and coordinating major (and probably even minor) releases in the way that Matthias outlines is a great idea. I agree with Thomas that bugfix releases should be easier and more frequently released. On Thu, Feb 9, 2017 at 6:53 AM Thomas Kluyver wrote: > On 9

Re: [jupyter] Formalizing preparing a release

On 9 February 2017 at 03:12, Matthias Bussonnier < bussonniermatth...@gmail.com> wrote: > For example, several developers were surprised yesterday with the > announcement of an upcoming notebook 5.0 release, and are now > struggling to catch up on what is new and to test their >

Re: [jupyter] Formalizing preparing a release

I'm certainly a fan. For coordinated releases across multiple, I'd be happy with a meta issue in the name/name package - ipython, ipykernel in ipython/ipython; jupyter_client, notebook, etc. in jupyter/jupyter. On Wed, Feb 8, 2017 at 7:12 PM, Matthias Bussonnier

[jupyter] Formalizing preparing a release

Hello all, It recently came to the attention to some of us that with the increasing number of projects we have it can be hard to follow when packages are going to be released, which often leads to very short windows of time to give feedback or test the new version with existing software. For