[Dovecot] 1.0.beta7
Sorry, the authentication problem still wasn't actually fixed in beta6. Now, this time I tested every possible authentication case that it really works.
I'll soon create a CVS branch which is going to stabilize into the 1.0 release. I won't add new features there so it shouldn't really get broken anymore, at least because of new features..
So, two changes in this release:
+ Added shutdown_clients setting to control if existing imap/pop3
processes should be killed when master is.
- Master login fixes, PLAIN authentication was still broken..Anyone wanna help pitch in for a faster PPC machine?
Fedora Core 4: http://fedora.ivazquez.net/yum/4/i386/RPMS.alternatives/dovecot-1.0-0.iva.10... http://fedora.ivazquez.net/yum/4/i386/SRPMS.alternatives/dovecot-1.0-0.iva.1...
http://fedora.ivazquez.net/yum/4/ppc/RPMS.alternatives/dovecot-1.0-0.iva.10.... http://fedora.ivazquez.net/yum/4/ppc/SRPMS.alternatives/dovecot-1.0-0.iva.10...
http://fedora.ivazquez.net/yum/4/x86_64/RPMS.alternatives/dovecot-1.0-0.iva.... http://fedora.ivazquez.net/yum/4/x86_64/SRPMS.alternatives/dovecot-1.0-0.iva...
Fedora Core 5: http://fedora.ivazquez.net/yum/5/i386/RPMS.alternatives/dovecot-1.0-0.iva.10... http://fedora.ivazquez.net/yum/5/i386/SRPMS.alternatives/dovecot-1.0-0.iva.1...
http://fedora.ivazquez.net/yum/5/ppc/RPMS.alternatives/dovecot-1.0-0.iva.10.... http://fedora.ivazquez.net/yum/5/ppc/SRPMS.alternatives/dovecot-1.0-0.iva.10...
http://fedora.ivazquez.net/yum/5/x86_64/RPMS.alternatives/dovecot-1.0-0.iva.... http://fedora.ivazquez.net/yum/5/x86_64/SRPMS.alternatives/dovecot-1.0-0.iva...
-- Ignacio Vazquez-Abrams <ivazquez@ivazquez.net> http://fedora.ivazquez.net/
gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
On Wed, 2006-04-12 at 10:41 -0400, Ignacio Vazquez-Abrams wrote:
Anyone wanna help pitch in for a faster PPC machine?
http://projects.ppczone.org/projects.php?program=OSW :P
johannes
Quoting Ignacio Vazquez-Abrams <ivazquez@ivazquez.net>:
Anyone wanna help pitch in for a faster PPC machine?
Faster than what?
-- Eric Rostetter The Department of Physics The University of Texas at Austin
Go Longhorns!
On Wed, 2006-04-12 at 21:48 -0500, Eric Jon Rostetter wrote:
Quoting Ignacio Vazquez-Abrams <ivazquez@ivazquez.net>:
Anyone wanna help pitch in for a faster PPC machine?
Faster than what?
Right now my PPC build machine is a B+W G3/300, one of the first NewWorld Macs, with 320MB of RAM. It does the trick, albeit slowly.
-- Ignacio Vazquez-Abrams <ivazquez@ivazquez.net> http://fedora.ivazquez.net/
gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
Good to hear this. I know you're a perfectionist but in the real world no one really expects a 1.00 version to be 100% so if you have a few issue with 1.00 then there cam be a 1.01, 1.02 etc. People really don't trust a product until it hits 1.02 anyhow. So - getting to the point - I'd suggest crossing the 1.0 line sooner than later.
Also - maybe it's time soon to start switching to RC (Release Candidate) numbering indicating to the world that beta is over and 1.0 is coming. Dovecot 1.0.RC1 ....
Timo Sirainen wrote:
I'll soon create a CVS branch which is going to stabilize into the 1.0 release. I won't add new features there so it shouldn't really get broken anymore, at least because of new features..
I completely disagree. If there are known bugs in a release, it should keep a beta designation. If you're ok running a software with known bugs then you should be equally ok to run a beta version. If you're not, then you don't run a beta version and accept that you won't have all the nifty new features.
One of the advantages of open source is that there are no market-imposed ship dates, so there's no reason to keep the baggage associated with them.
On Wed, 12 Apr 2006, Marc Perkel wrote:
Good to hear this. I know you're a perfectionist but in the real world no one really expects a 1.00 version to be 100% so if you have a few issue with 1.00 then there cam be a 1.01, 1.02 etc. People really don't trust a product until it hits 1.02 anyhow. So - getting to the point - I'd suggest crossing the 1.0 line sooner than later.
Also - maybe it's time soon to start switching to RC (Release Candidate) numbering indicating to the world that beta is over and 1.0 is coming. Dovecot 1.0.RC1 ....
Timo Sirainen wrote:
I'll soon create a CVS branch which is going to stabilize into the 1.0 release. I won't add new features there so it shouldn't really get broken anymore, at least because of new features..
Continuing with the top posting mode :-( ...
What has been needed for at least the past year is to separate feature development from bug fixing.
The strong evidence for this need is that several of the beta releases have been quickly followed by another release, (often within hours) solely to fix the previous release. IMHO, the Dovecot project has matured to a point where the biggest impediment to usage in mission critical situations is stability of releases.
Timo, please do understand that I value the effort you and those who work with you have expended on this project. This project is greatly needed by the Open Source community and I applaud the results of your effort. I also want to urge you to separate development from bug fixing by making a formal release, the sooner the better.
Making a formal release need not stop feature development, even with v1.x. Just use the venerable a.b.c model, where "c" level releases are bug fixes and "b" level releases indicate new features.
Thanks, Ray
Ben wrote:
I completely disagree. If there are known bugs in a release, it should keep a beta designation. If you're ok running a software with known bugs then you should be equally ok to run a beta version. If you're not, then you don't run a beta version and accept that you won't have all the nifty new features.
One of the advantages of open source is that there are no market-imposed ship dates, so there's no reason to keep the baggage associated with them.
On Wed, 12 Apr 2006, Marc Perkel wrote:
Good to hear this. I know you're a perfectionist but in the real world no one really expects a 1.00 version to be 100% so if you have a few issue with 1.00 then there cam be a 1.01, 1.02 etc. People really don't trust a product until it hits 1.02 anyhow. So - getting to the point - I'd suggest crossing the 1.0 line sooner than later.
Also - maybe it's time soon to start switching to RC (Release Candidate) numbering indicating to the world that beta is over and 1.0 is coming. Dovecot 1.0.RC1 ....
Timo Sirainen wrote:
I'll soon create a CVS branch which is going to stabilize into the 1.0 release. I won't add new features there so it shouldn't really get broken anymore, at least because of new features..
Dies on OpenBSD/macppc
Apr 12 16:37:50 gir dovecot: IMAP(phessler): Unrecognized event: kevent{.ident = 2, .filter = 0xfffffffe, .flags = 0x0001, .fflags=0x00000000, .data = 0x00004000} Apr 12 16:37:50 gir dovecot: imap-login: Login: user=<phessler>, method=PLAIN, rip=foo, lip=bar, TLS Apr 12 16:37:50 gir dovecot: child 1244 (imap) killed with signal 6
On Wed, 12 Apr 2006 14:53:45 +0300 Timo Sirainen <tss@iki.fi> wrote:
: Sorry, the authentication problem still wasn't actually fixed in beta6. : Now, this time I tested every possible authentication case that it : really works. : : I'll soon create a CVS branch which is going to stabilize into the 1.0 : release. I won't add new features there so it shouldn't really get : broken anymore, at least because of new features.. : : So, two changes in this release: : : + Added shutdown_clients setting to control if existing imap/pop3 : processes should be killed when master is. : - Master login fixes, PLAIN authentication was still broken.. :
-- Who made the world I cannot tell; 'Tis made, and here am I in hell. My hand, though now my knuckles bleed, I never soiled with such a deed. -- A. E. Housman
participants (8)
-
Ben
-
Eric Jon Rostetter
-
Ignacio Vazquez-Abrams
-
Johannes Berg
-
Marc Perkel
-
Peter Hessler
-
Raymond Lillard
-
Timo Sirainen