[Dovecot] 1.0.rc18 released
http://dovecot.org/releases/dovecot-1.0.rc18.tar.gz http://dovecot.org/releases/dovecot-1.0.rc18.tar.gz.sig
I think we're quite near v1.0 now.
* ACL plugin + Maildir: Moved dovecot-acl file from control directory
to maildir. To prevent accidents caused by this change, Dovecot
kills itself if it finds dovecot-acl file from the control directory.
* When opening a maildir, check if tmp/'s atime is over 8h old. If it
is, delete files in it with ctime older than 36h. However if
atime - ctime > 36h, it means that there's nothing to be deleted and
the scanning isn't done. We update atime ourself if filesystem is
mounted with noatime.
* base_dir doesn't need to be group-readable, don't force it.
* mail_read_mmaped setting is deprecated and possibly broken. It's now
removed from dovecot-example.conf, but it still works for now.
* Removed also umask setting from dovecot-example.conf since currently
it doesn't do what it's supposed to.
+ Authentication cache caches now also userdb data.
+ Added mail_log plugin to log various mail operations. Currently it
logs mail copies, deletions, expunges and mailbox deletions.
- dict quota: messages=n parameter actually changed storage limit.
- A lot of fixes to handling index files. This should fix almost all
of the problems ever reported.
- LDAP: auth_bind=yes was more or less broken.
- Saved mails and dovecot-keywords file didn't set the group from
dovecot-shared file.
- Fixed potential assert-crash while searching messages
- Fixed some crashes with invalid X-UID headers in mboxes
- If you didn't have a namespace with empty prefix, giving STATUS
command for a non-existing namespace caused the connection to give
"NO Unknown namespace" errors for all the future commands.Timo Sirainen wrote:
http://dovecot.org/releases/dovecot-1.0.rc18.tar.gz http://dovecot.org/releases/dovecot-1.0.rc18.tar.gz.sig
I think we're quite near v1.0 now.
- Added mail_log plugin to log various mail operations. Currently it logs mail copies, deletions, expunges and mailbox deletions.
Just a suggestion... maybe put a freeze on new features and stabilize 1.0 with the current feature set and a known-bugs list. The config file has already been revised several times throughout the RC series, so maybe that means that too much development is happening under a "release candidate" banner?
I'm looking at this from a production admin's point of view: It's getting somewhat amusing to see more and more RCs, when the core functionality is pretty much "done". Problem is, RCs are not really preferred for a production deployment in the eyes of nontechnical people. What a production environment needs is a nailed down version that doesn't change features and only puts in critical fixes.
From what I can see, dovecot could have released a 1.0 two or three RCs ago and released bugfixes via a 1.0.1, 1.0.2, etc. branch, with new development in a 1.1-beta line. Timo, we believe in your code... it works... so *please* slap a real release number on it, and we can finally convince others that it's time to switch. :)
-- -- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>
On Mon, 2007-01-22 at 12:34 -0500, Todd Vierling wrote:
From what I can see, dovecot could have released a 1.0 two or three RCs ago and released bugfixes via a 1.0.1, 1.0.2, etc. branch, with new development in a 1.1-beta line. Timo, we believe in your code... it works... so *please* slap a real release number on it, and we can finally convince others that it's time to switch. :)
I know the naming for Dovecot has sucked for years, but I haven't really seen any better ways to do it. I made the mistake in releasing v0.90 way too early.
Most of the new features in 1.0 RCs have been either trivial enough not to cause any destabilization or they've been implemented completely in plugins. Some of them have been paid for, and since they were done anyway I thought I might as well put them into RCs than maintain a list of patches that I have to keep updated constantly.
And sure, I suppose I could have just released v1.0 months ago, but I don't think it would have really changed anything else except to make more people try Dovecot, and possibly make them disappointed when they find bugs in what is supposed to be stable release.
I've for a long time thought that I'll release v1.0 once several weeks have passed and I haven't heard of any problems relating to index files and other such somewhat common random problems. I thought RC18 was supposed to fix all of them, but looks like there are again two more problems that more than one people are seeing.. I'd hate to release v1.0 and include in known bugs list things like "randomly crashes" and "randomly logs errors".
And 1.1-beta line already kind of exists in CVS HEAD. It has *huge* changes. I wish v1.0 were out just so I could start making v1.1 releases and get more people to test those changes.
On 1/22/07, Timo Sirainen <tss@iki.fi> wrote:
Most of the new features in 1.0 RCs have been either trivial enough not to cause any destabilization or they've been implemented completely in plugins. Some of them have been paid for,
I like the sound of that. Sounds to me like some folks are expressing serious interest.
I've for a long time thought that I'll release v1.0 once several weeks have passed and I haven't heard of any problems relating to index files and other such somewhat common random problems. I thought RC18 was supposed to fix all of them, but looks like there are again two more problems that more than one people are seeing.. I'd hate to release v1.0 and include in known bugs list things like "randomly crashes" and "randomly logs errors".
Do keep in mind that imap-uw still has bugs today that cause "random crashes", and its logging has always been crappy. That is not an excuse, but it points out that Dovecot is *at least* as good as UW IMAP today. ;)
That said, I'm still cheering you on towards the finish line, and thanks for the great work.
-- -- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>
Todd Vierling wrote:
Timo, we believe in your code... it works... so *please* slap a real release number on it, and we can finally convince others that it's time to switch. :)
RHEL5 will ship with at least version 1.0.rc7, so once RHEL5 is release near the end of february, I think a lot of people will start using it ;)
Oliver
-- Oliver Schulze L. | Get my e-mail after a captcha in: Asuncion - Paraguay | http://tinymailto.com/oliver
On Tue, Jan 23, 2007 at 11:37:39AM -0300, Oliver Schulze L. wrote:
RHEL5 will ship with at least version 1.0.rc7, so once RHEL5 is release near the end of february, I think a lot of people will start using it ;)
I've found this one of the most problem-free versions so far.. I only recently upgraded a production-system to 1.0rc16, which is running fine too.
GeertGeert Hendrickx wrote:
I've found this one of the most problem-free versions so far.. I only recently upgraded a production-system to 1.0rc16, which is running fine too.
Geert
Mee too, I stopped upgrading on rc8 and it is rock solid in many production servers that I administer
Oliver
-- Oliver Schulze L. | Get my e-mail after a captcha in: Asuncion - Paraguay | http://tinymailto.com/oliver
participants (4)
-
Geert Hendrickx
-
Oliver Schulze L.
-
Timo Sirainen
-
Todd Vierling