[Matplotlib-devel] release schedule

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[Matplotlib-devel] release schedule

tcaswell
Folks,

I think we should aim for 3.0.1 and 2.2.4 by the end of October and 3.1 in March - April 2019.

Thoughts?

Tom

_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
Reply | Threaded
Open this post in threaded view
|

Re: release schedule

Ryan May-3
I think those are reasonable. My only suggestion would be to try to increase the likelihood of hitting the schedule for 3.1 by starting the branching/RC process sooner. So maybe Feb or even Jan to start? It seems like part of our problem is that the stabilization/close out process takes longer than anticipated.

Ryan

On Tue, Oct 9, 2018 at 8:28 PM Thomas Caswell <[hidden email]> wrote:
Folks,

I think we should aim for 3.0.1 and 2.2.4 by the end of October and 3.1 in March - April 2019.

Thoughts?

Tom
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
--
Ryan May


_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
Reply | Threaded
Open this post in threaded view
|

Re: release schedule

Paul Hobson-2
Agree with Ryan.

On Wed, Oct 10, 2018 at 11:36 AM Ryan May <[hidden email]> wrote:
I think those are reasonable. My only suggestion would be to try to increase the likelihood of hitting the schedule for 3.1 by starting the branching/RC process sooner. So maybe Feb or even Jan to start? It seems like part of our problem is that the stabilization/close out process takes longer than anticipated.

Ryan

On Tue, Oct 9, 2018 at 8:28 PM Thomas Caswell <[hidden email]> wrote:
Folks,

I think we should aim for 3.0.1 and 2.2.4 by the end of October and 3.1 in March - April 2019.

Thoughts?

Tom
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
--
Ryan May

_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel

_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
Reply | Threaded
Open this post in threaded view
|

Re: release schedule

tcaswell
Ok, so looking at my calendar, aiming to do 3.0.1 and 2.2.4 Nov 3-4 seems realistic.  Even if we don't fix everything that has been reported, we have enough bug-fixes already in it will be worth it.

Lets plan to create the 3.1.x branch on Jan 31, 2019, RCs in Feburary and a final release sometime in March?

Tom


On Wed, Oct 10, 2018 at 2:59 PM Paul Hobson <[hidden email]> wrote:
Agree with Ryan.

On Wed, Oct 10, 2018 at 11:36 AM Ryan May <[hidden email]> wrote:
I think those are reasonable. My only suggestion would be to try to increase the likelihood of hitting the schedule for 3.1 by starting the branching/RC process sooner. So maybe Feb or even Jan to start? It seems like part of our problem is that the stabilization/close out process takes longer than anticipated.

Ryan

On Tue, Oct 9, 2018 at 8:28 PM Thomas Caswell <[hidden email]> wrote:
Folks,

I think we should aim for 3.0.1 and 2.2.4 by the end of October and 3.1 in March - April 2019.

Thoughts?

Tom
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
--
Ryan May

_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel

_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
Reply | Threaded
Open this post in threaded view
|

Re: release schedule

Nelle Varoquaux
My two cents is that the branching process should not be happening to soon: can we do a feature freeze in master instead? Managing branches for long period of time can be a pain in the butt…

Cheers,
N

On Wed, 10 Oct 2018 at 18:50, Thomas Caswell <[hidden email]> wrote:
Ok, so looking at my calendar, aiming to do 3.0.1 and 2.2.4 Nov 3-4 seems realistic.  Even if we don't fix everything that has been reported, we have enough bug-fixes already in it will be worth it.

Lets plan to create the 3.1.x branch on Jan 31, 2019, RCs in Feburary and a final release sometime in March?

Tom


On Wed, Oct 10, 2018 at 2:59 PM Paul Hobson <[hidden email]> wrote:
Agree with Ryan.

On Wed, Oct 10, 2018 at 11:36 AM Ryan May <[hidden email]> wrote:
I think those are reasonable. My only suggestion would be to try to increase the likelihood of hitting the schedule for 3.1 by starting the branching/RC process sooner. So maybe Feb or even Jan to start? It seems like part of our problem is that the stabilization/close out process takes longer than anticipated.

Ryan

On Tue, Oct 9, 2018 at 8:28 PM Thomas Caswell <[hidden email]> wrote:
Folks,

I think we should aim for 3.0.1 and 2.2.4 by the end of October and 3.1 in March - April 2019.

Thoughts?

Tom
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
--
Ryan May

_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel

_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
Reply | Threaded
Open this post in threaded view
|

Re: release schedule

Ryan May-3
Nelle,

I hear what you're saying about long-lived branches, but given that we do bug fix releases off that branch, it's going to be around for a long time any way; IMO the point is moot.

I'm also not sure that anything that impedes our ability to merge PRs (such as a feature freeze on master) is a good idea overall.

Ryan

On Wed, Oct 10, 2018 at 8:01 PM Nelle Varoquaux <[hidden email]> wrote:
My two cents is that the branching process should not be happening to soon: can we do a feature freeze in master instead? Managing branches for long period of time can be a pain in the butt…

Cheers,
N

On Wed, 10 Oct 2018 at 18:50, Thomas Caswell <[hidden email]> wrote:
Ok, so looking at my calendar, aiming to do 3.0.1 and 2.2.4 Nov 3-4 seems realistic.  Even if we don't fix everything that has been reported, we have enough bug-fixes already in it will be worth it.

Lets plan to create the 3.1.x branch on Jan 31, 2019, RCs in Feburary and a final release sometime in March?

Tom


On Wed, Oct 10, 2018 at 2:59 PM Paul Hobson <[hidden email]> wrote:
Agree with Ryan.

On Wed, Oct 10, 2018 at 11:36 AM Ryan May <[hidden email]> wrote:
I think those are reasonable. My only suggestion would be to try to increase the likelihood of hitting the schedule for 3.1 by starting the branching/RC process sooner. So maybe Feb or even Jan to start? It seems like part of our problem is that the stabilization/close out process takes longer than anticipated.

Ryan

On Tue, Oct 9, 2018 at 8:28 PM Thomas Caswell <[hidden email]> wrote:
Folks,

I think we should aim for 3.0.1 and 2.2.4 by the end of October and 3.1 in March - April 2019.

Thoughts?

Tom
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
--
Ryan May

_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel


--
Ryan May


_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
Reply | Threaded
Open this post in threaded view
|

Re: release schedule

Nelle Varoquaux
It's a question of incentives. It's always "more cool" to implement features. If you have a feature freezes, but nothing can get merged before the 10 bugs have been fixed, you'll have more chance of people working on the bug fixes.
I distinctively remember the 2.0 situation where not many of us where tackling the 10 remaining tickets, and where we (in my opinion) really struggled to get the release out of the door.

Cheers,
N

On Fri, 12 Oct 2018 at 10:33, Ryan May <[hidden email]> wrote:
Nelle,

I hear what you're saying about long-lived branches, but given that we do bug fix releases off that branch, it's going to be around for a long time any way; IMO the point is moot.

I'm also not sure that anything that impedes our ability to merge PRs (such as a feature freeze on master) is a good idea overall.

Ryan

On Wed, Oct 10, 2018 at 8:01 PM Nelle Varoquaux <[hidden email]> wrote:
My two cents is that the branching process should not be happening to soon: can we do a feature freeze in master instead? Managing branches for long period of time can be a pain in the butt…

Cheers,
N

On Wed, 10 Oct 2018 at 18:50, Thomas Caswell <[hidden email]> wrote:
Ok, so looking at my calendar, aiming to do 3.0.1 and 2.2.4 Nov 3-4 seems realistic.  Even if we don't fix everything that has been reported, we have enough bug-fixes already in it will be worth it.

Lets plan to create the 3.1.x branch on Jan 31, 2019, RCs in Feburary and a final release sometime in March?

Tom


On Wed, Oct 10, 2018 at 2:59 PM Paul Hobson <[hidden email]> wrote:
Agree with Ryan.

On Wed, Oct 10, 2018 at 11:36 AM Ryan May <[hidden email]> wrote:
I think those are reasonable. My only suggestion would be to try to increase the likelihood of hitting the schedule for 3.1 by starting the branching/RC process sooner. So maybe Feb or even Jan to start? It seems like part of our problem is that the stabilization/close out process takes longer than anticipated.

Ryan

On Tue, Oct 9, 2018 at 8:28 PM Thomas Caswell <[hidden email]> wrote:
Folks,

I think we should aim for 3.0.1 and 2.2.4 by the end of October and 3.1 in March - April 2019.

Thoughts?

Tom
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
--
Ryan May

_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel


--
Ryan May


_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
Reply | Threaded
Open this post in threaded view
|

Re: release schedule

anntzer.lee
I have no problem with branching 3.1 early (we are already managing backports into the very-long-lived 2.2.x branch and that doesn't seem to be a problem at all).  I'm not sure why you'd want to prevent feature merges to master for a month.  It's not the end of the world if 3.1 takes 45 days or even 60 to be released instead of 30...
Antony

On Fri, Oct 12, 2018 at 8:54 PM Nelle Varoquaux <[hidden email]> wrote:
It's a question of incentives. It's always "more cool" to implement features. If you have a feature freezes, but nothing can get merged before the 10 bugs have been fixed, you'll have more chance of people working on the bug fixes.
I distinctively remember the 2.0 situation where not many of us where tackling the 10 remaining tickets, and where we (in my opinion) really struggled to get the release out of the door.

Cheers,
N

On Fri, 12 Oct 2018 at 10:33, Ryan May <[hidden email]> wrote:
Nelle,

I hear what you're saying about long-lived branches, but given that we do bug fix releases off that branch, it's going to be around for a long time any way; IMO the point is moot.

I'm also not sure that anything that impedes our ability to merge PRs (such as a feature freeze on master) is a good idea overall.

Ryan

On Wed, Oct 10, 2018 at 8:01 PM Nelle Varoquaux <[hidden email]> wrote:
My two cents is that the branching process should not be happening to soon: can we do a feature freeze in master instead? Managing branches for long period of time can be a pain in the butt…

Cheers,
N

On Wed, 10 Oct 2018 at 18:50, Thomas Caswell <[hidden email]> wrote:
Ok, so looking at my calendar, aiming to do 3.0.1 and 2.2.4 Nov 3-4 seems realistic.  Even if we don't fix everything that has been reported, we have enough bug-fixes already in it will be worth it.

Lets plan to create the 3.1.x branch on Jan 31, 2019, RCs in Feburary and a final release sometime in March?

Tom


On Wed, Oct 10, 2018 at 2:59 PM Paul Hobson <[hidden email]> wrote:
Agree with Ryan.

On Wed, Oct 10, 2018 at 11:36 AM Ryan May <[hidden email]> wrote:
I think those are reasonable. My only suggestion would be to try to increase the likelihood of hitting the schedule for 3.1 by starting the branching/RC process sooner. So maybe Feb or even Jan to start? It seems like part of our problem is that the stabilization/close out process takes longer than anticipated.

Ryan

On Tue, Oct 9, 2018 at 8:28 PM Thomas Caswell <[hidden email]> wrote:
Folks,

I think we should aim for 3.0.1 and 2.2.4 by the end of October and 3.1 in March - April 2019.

Thoughts?

Tom
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
--
Ryan May

_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel


--
Ryan May

_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel

_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
Reply | Threaded
Open this post in threaded view
|

Re: release schedule

tcaswell
I am also not worried about forking early.  Meeseeksdev makes it pretty easy to manage backports. I am cautious about over-learning from the 2.0 release process.  Mike and I drastically under-estimated the amount of work that would be required to begin with and I ended up being the bottle neck on a number of issues at the end.

I think we are too distributed with too many volunteer devs to freeze master for a few weeks (on the other hand, freezing master is definitely how we do this on my day-job projects!).

My main take away from this thread is that there is agreement about the dates and discussion about process.

Tom

On Sat, Oct 13, 2018 at 4:26 PM Antony Lee <[hidden email]> wrote:
I have no problem with branching 3.1 early (we are already managing backports into the very-long-lived 2.2.x branch and that doesn't seem to be a problem at all).  I'm not sure why you'd want to prevent feature merges to master for a month.  It's not the end of the world if 3.1 takes 45 days or even 60 to be released instead of 30...
Antony

On Fri, Oct 12, 2018 at 8:54 PM Nelle Varoquaux <[hidden email]> wrote:
It's a question of incentives. It's always "more cool" to implement features. If you have a feature freezes, but nothing can get merged before the 10 bugs have been fixed, you'll have more chance of people working on the bug fixes.
I distinctively remember the 2.0 situation where not many of us where tackling the 10 remaining tickets, and where we (in my opinion) really struggled to get the release out of the door.

Cheers,
N

On Fri, 12 Oct 2018 at 10:33, Ryan May <[hidden email]> wrote:
Nelle,

I hear what you're saying about long-lived branches, but given that we do bug fix releases off that branch, it's going to be around for a long time any way; IMO the point is moot.

I'm also not sure that anything that impedes our ability to merge PRs (such as a feature freeze on master) is a good idea overall.

Ryan

On Wed, Oct 10, 2018 at 8:01 PM Nelle Varoquaux <[hidden email]> wrote:
My two cents is that the branching process should not be happening to soon: can we do a feature freeze in master instead? Managing branches for long period of time can be a pain in the butt…

Cheers,
N

On Wed, 10 Oct 2018 at 18:50, Thomas Caswell <[hidden email]> wrote:
Ok, so looking at my calendar, aiming to do 3.0.1 and 2.2.4 Nov 3-4 seems realistic.  Even if we don't fix everything that has been reported, we have enough bug-fixes already in it will be worth it.

Lets plan to create the 3.1.x branch on Jan 31, 2019, RCs in Feburary and a final release sometime in March?

Tom


On Wed, Oct 10, 2018 at 2:59 PM Paul Hobson <[hidden email]> wrote:
Agree with Ryan.

On Wed, Oct 10, 2018 at 11:36 AM Ryan May <[hidden email]> wrote:
I think those are reasonable. My only suggestion would be to try to increase the likelihood of hitting the schedule for 3.1 by starting the branching/RC process sooner. So maybe Feb or even Jan to start? It seems like part of our problem is that the stabilization/close out process takes longer than anticipated.

Ryan

On Tue, Oct 9, 2018 at 8:28 PM Thomas Caswell <[hidden email]> wrote:
Folks,

I think we should aim for 3.0.1 and 2.2.4 by the end of October and 3.1 in March - April 2019.

Thoughts?

Tom
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
--
Ryan May

_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel


--
Ryan May

_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel


--
Thomas Caswell
[hidden email]

_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
Reply | Threaded
Open this post in threaded view
|

Re: release schedule

tcaswell
If people have bandwidth and a mac, I think the highest priority thing left for 3.0.1 is the bouncing rocket on OSX



Tom

On Tue, Oct 16, 2018 at 8:48 AM Thomas Caswell <[hidden email]> wrote:
I am also not worried about forking early.  Meeseeksdev makes it pretty easy to manage backports. I am cautious about over-learning from the 2.0 release process.  Mike and I drastically under-estimated the amount of work that would be required to begin with and I ended up being the bottle neck on a number of issues at the end.

I think we are too distributed with too many volunteer devs to freeze master for a few weeks (on the other hand, freezing master is definitely how we do this on my day-job projects!).

My main take away from this thread is that there is agreement about the dates and discussion about process.

Tom

On Sat, Oct 13, 2018 at 4:26 PM Antony Lee <[hidden email]> wrote:
I have no problem with branching 3.1 early (we are already managing backports into the very-long-lived 2.2.x branch and that doesn't seem to be a problem at all).  I'm not sure why you'd want to prevent feature merges to master for a month.  It's not the end of the world if 3.1 takes 45 days or even 60 to be released instead of 30...
Antony

On Fri, Oct 12, 2018 at 8:54 PM Nelle Varoquaux <[hidden email]> wrote:
It's a question of incentives. It's always "more cool" to implement features. If you have a feature freezes, but nothing can get merged before the 10 bugs have been fixed, you'll have more chance of people working on the bug fixes.
I distinctively remember the 2.0 situation where not many of us where tackling the 10 remaining tickets, and where we (in my opinion) really struggled to get the release out of the door.

Cheers,
N

On Fri, 12 Oct 2018 at 10:33, Ryan May <[hidden email]> wrote:
Nelle,

I hear what you're saying about long-lived branches, but given that we do bug fix releases off that branch, it's going to be around for a long time any way; IMO the point is moot.

I'm also not sure that anything that impedes our ability to merge PRs (such as a feature freeze on master) is a good idea overall.

Ryan

On Wed, Oct 10, 2018 at 8:01 PM Nelle Varoquaux <[hidden email]> wrote:
My two cents is that the branching process should not be happening to soon: can we do a feature freeze in master instead? Managing branches for long period of time can be a pain in the butt…

Cheers,
N

On Wed, 10 Oct 2018 at 18:50, Thomas Caswell <[hidden email]> wrote:
Ok, so looking at my calendar, aiming to do 3.0.1 and 2.2.4 Nov 3-4 seems realistic.  Even if we don't fix everything that has been reported, we have enough bug-fixes already in it will be worth it.

Lets plan to create the 3.1.x branch on Jan 31, 2019, RCs in Feburary and a final release sometime in March?

Tom


On Wed, Oct 10, 2018 at 2:59 PM Paul Hobson <[hidden email]> wrote:
Agree with Ryan.

On Wed, Oct 10, 2018 at 11:36 AM Ryan May <[hidden email]> wrote:
I think those are reasonable. My only suggestion would be to try to increase the likelihood of hitting the schedule for 3.1 by starting the branching/RC process sooner. So maybe Feb or even Jan to start? It seems like part of our problem is that the stabilization/close out process takes longer than anticipated.

Ryan

On Tue, Oct 9, 2018 at 8:28 PM Thomas Caswell <[hidden email]> wrote:
Folks,

I think we should aim for 3.0.1 and 2.2.4 by the end of October and 3.1 in March - April 2019.

Thoughts?

Tom
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
--
Ryan May

_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel


--
Ryan May

_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel


--
Thomas Caswell
[hidden email]


--
Thomas Caswell
[hidden email]

_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel