Cyrus 2.3.13 RC2

Ken Murchison murch at andrew.cmu.edu
Tue Oct 7 08:52:30 EDT 2008


Kenneth Marshall wrote:
> On Tue, Oct 07, 2008 at 12:18:01PM +0200, Simon Matter wrote:
>>> I just put together a second release candidate for Cyrus 2.3.13.  I'd
>>> appreciate any independent testing before I release this to the masses.
>>>
>>> http://www.contrib.andrew.cmu.edu/~murch/cyrus-imapd-2.3.13rc2.tar.gz
>>> http://www.contrib.andrew.cmu.edu/~murch/cyrus-imapd-2.3.13rc2.tar.gz.sig
>>>
>>>
>>> Noteworthy changes:
>>>
>>> * Added an experimental "sql" backend for cyrusdb.  Currently MySQL,
>>>    PostgreSQL, and SQLite are supported.
>>> * Added support for IMAP [CAPABILITY] response code to client-side
>>>    of Murder proxies.
>>> * Added support for ManageSieve auto-capability response after
>>>    STARTTLS and after AUTH with a SASL security layer.
>>> * Made MAXWORD and MAXQUOTED sizes configurable via imapd.conf
>>> * Rewrote cyrusdb_quotalegacy.c to use readir()
>>>    rather than glob.c.  This avoids a potential crash due to
>>>    conflicts between glibc and Heimdal implementations of glob().
>>> * Added support for fulldirhash to 'ctl_mboxlist -v'
>>> * Several skiplist transaction bugfixes.
>>> * cyr_expire no longer has a default of 0 (zero) for -X and -D.
>>>    These options must be used explicitly in order to have the desired
>>>    effect.
>>> * Added sieve_utf8fileinto option.
>>>
>>> Check doc/changes.html for a complete list of changes.
>>>
>>> If there are any outstanding issues that you believe still need to be
>>> addressed in 2.3.13, please let me know.
>> I did some test builds on different systems and found that postgresql
>> support doesn't work with postgresql 7.1.x and 7.2.x as shown in the error
>> below. I understand that these are old versions but if there is an easy
>> workaround for the problem it would still be nice.
>>
>> One question to the new sieve_utf8fileinto options, is the default that it
>> behaves like old cyrus versions?
>>
>> Thanks,
>> Simon
>>
> 
> There have been 5 major releases of PostgreSQL since 7.2 was released
> and 7.2 is EOL in the next few months. I think it is completely reasonable
> to not support version 7.1/7.2 in a new system considering that 7.1 is
> EOL and 7.2 will be shortly.

I wasn't aware of the release history, thanks for that.

Given this, I agree that support for 7.1/7.2 isn't necessary, especially 
since the cyrusdb_sql.c code is experimental and not built by default. 
If somebody really wants/needs 7.1/7.2 for Cyrus, they can send a patch.

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University


More information about the Cyrus-devel mailing list