Proposing a new release calendar

[Augie Fackler]

Revising the calendar seems fine. I think “on or after” dates make sense, especially as release management often involves corporate contributors.

> On Nov 29, 2021, at 9:58 AM, Raphaël Gomès <raphael.gomes at octobus.net> wrote:
> 
> This is a good point, though these are "on or around" dates, which means that usually the next work day is the actual release day.
> 
> We've already had a Jan 1 date since 2.0 (IIUC), so this shouldn't be too much of a problem, though I can see going for an explicit Jan 3 or something to clarify it.
> 
> On 11/29/21 3:55 PM, Julien Cristau wrote:
>> On Mon, Nov 22, 2021 at 11:34:19AM +0100, Raphaël Gomès wrote:
>>> Hi all,
>>> 
>>> This email is in part prompted by the previous releases' delay, but also by
>>> discussions around release timing we've previously had. 6.0 is very likely
>>> coming out tomorrow with a delay of 22 days due to a lot of issues with
>>> Windows Python 3 support. I was going to propose to move the 6.1 release to
>>> March 1st 2022 just this once, but thought about doing this more
>>> permanently.
>>> 
>>> With the relatively limited resources we have and the current calendar
>>> including a release that falls right in the middle of summer where activity
>>> is lowest and help is less available, I propose that we go back to 3 major
>>> releases a year with the following calendar:
>>> 
>>> Freeze date | Major Release | Minor | Minor | Minor
>>> ---------------------------------------------------
>>> Feb 15      | Mar 1         | Apr 1 | May 1 | Jun 1
>>> Jun 17      | Jul 1         | Aug 1 | Sep 1 | Oct 1
>>> Oct 18      | Nov 1         | Dec 1 | Jan 1 | Feb 1
>>> 
>>> What do you all think?
>>> 
>> Is Jan 1 a good choice there, for even a minor release?  That seems
>> likely to either slip or ruin somebody's holidays...
>> 
>> Cheers,
>> Julien