[Matplotlib-devel] release schedule

Thomas Caswell tcaswell at gmail.com
Tue Oct 16 08:53:21 EDT 2018


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

https://github.com/matplotlib/matplotlib/issues/12188


Tom

On Tue, Oct 16, 2018 at 8:48 AM Thomas Caswell <tcaswell at gmail.com> 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 <anntzer.lee at gmail.com> 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 <
>> nelle.varoquaux at gmail.com> 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 <rmay31 at gmail.com> 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 <
>>>> nelle.varoquaux at gmail.com> 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 <tcaswell at gmail.com>
>>>>> 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 <pmhobson at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Agree with Ryan.
>>>>>>>
>>>>>>> On Wed, Oct 10, 2018 at 11:36 AM Ryan May <rmay31 at gmail.com> 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 <tcaswell at gmail.com>
>>>>>>>> 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
>>>>>>>>> Matplotlib-devel at python.org
>>>>>>>>> https://mail.python.org/mailman/listinfo/matplotlib-devel
>>>>>>>>>
>>>>>>>> --
>>>>>>>> Ryan May
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Matplotlib-devel mailing list
>>>>>>>> Matplotlib-devel at python.org
>>>>>>>> https://mail.python.org/mailman/listinfo/matplotlib-devel
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>> Matplotlib-devel mailing list
>>>>>> Matplotlib-devel at python.org
>>>>>> https://mail.python.org/mailman/listinfo/matplotlib-devel
>>>>>>
>>>>> _______________________________________________
>>>>> Matplotlib-devel mailing list
>>>>> Matplotlib-devel at python.org
>>>>> https://mail.python.org/mailman/listinfo/matplotlib-devel
>>>>>
>>>>
>>>>
>>>> --
>>>> Ryan May
>>>>
>>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Matplotlib-devel at python.org
>>> https://mail.python.org/mailman/listinfo/matplotlib-devel
>>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Matplotlib-devel at python.org
>> https://mail.python.org/mailman/listinfo/matplotlib-devel
>>
>
>
> --
> Thomas Caswell
> tcaswell at gmail.com
>


-- 
Thomas Caswell
tcaswell at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20181016/132050ba/attachment-0001.html>


More information about the Matplotlib-devel mailing list