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.go...@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 _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
