Re: yearly release cycle

Dear Ricardo and the Cyrus IMAP community, I strongly support time-based releases. 3.2 in March 2020 sounds fantastic. JMAP in a stable release: yes! FYI, we use Cyrus IMAP as part of WikiSuite: https://wikisuite.org/Cyrus-IMAP Another component of WikiSuite is Tiki Wiki CMS Groupware. The Tiki

Re: yearly release cycle

Thanks, invite sent! :) On Tue, Dec 24, 2019, at 2:03 AM, Quanah Gibson-Mount wrote: > > > --On Monday, December 23, 2019 11:36 AM +1100 ellie timoney > wrote: > > > I tracked down Quanah's github account from a recent pull request, and > > sent through an invitation to the cyrusimap organisa

Re: yearly release cycle

--On Monday, December 23, 2019 11:36 AM +1100 ellie timoney wrote: I tracked down Quanah's github account from a recent pull request, and sent through an invitation to the cyrusimap organisation. Not sure what Howard Chu's email address or github username is? I can invite him too once I

Re: yearly release cycle

I tracked down Quanah's github account from a recent pull request, and sent through an invitation to the cyrusimap organisation. Not sure what Howard Chu's email address or github username is? I can invite him too once I know. Cheers, ellie On Sun, Dec 22, 2019, at 12:52 AM, Ken Murchison wr

Re: yearly release cycle

Quanah, I will try to make this happen next week. On 12/20/19 10:15 PM, Quanah Gibson-Mount wrote: --On Friday, December 20, 2019 9:02 PM -0500 Ricardo Signes wrote: I think there was some discussion / decision on this a while back, but I don't remember.  cyrus-sasl always floats just o

Re: yearly release cycle

--On Friday, December 20, 2019 9:02 PM -0500 Ricardo Signes wrote: I think there was some discussion / decision on this a while back, but I don't remember. cyrus-sasl always floats just outside my field of vision… I think I'll be talking to Ken on Monday, who can clear things up. Last

Re: yearly release cycle

On Wed, Dec 18, 2019, at 05:13, Дилян Палаузов wrote: > The email of Quanah Gibson-Mount from 25 July about the general policy on > integrating patches in Cyrus SASL is not > answered. > > Will the time–based release policy also apply to Cyrus SASL? I think there was some discussion / decision o

Re: yearly release cycle

Hello! This is a very good idea! In particular it makes the gap between development code and stable code smaller. Thus fixes for the stable code will be very similar to fixes on the development code. Of course, providing fixes, like optimizations, makes only sense if it is predictable whether

Re: yearly release cycle

On Tue, Dec 17, 2019, at 12:58, Anatoli wrote: > Hi Ricardo, Hi! > But I couldn't understand from the description what are the benefits of > tying major releases to certain calendar dates vs to make a release when > certain desired features are implemented and well tested. By promising a new maj

Re: yearly release cycle

Hi Ricardo, I find interesting some ideas in the proposed changes, especially I like this: "uniform substring like “unstable”" (with startup-time warnings if they change or become stable) and "Maintenance releases should be no-brainers to install... This means that once you’re on 3.4.0, you can al

Re: yearly release cycle

This all seems reasonable to me and I'm in favor of moving forward with this plan. On 12/13/19 9:59 AM, Ricardo Signes wrote: Hey, remember last month when I asked about releasing Cyrus v3.2 ? That thread had som

yearly release cycle

Hey, remember last month when I asked about releasing Cyrus v3.2 ? That thread had some more conversation about what needs to get done before v3.2, and I wanted to come back to it and turn some things on their head. R