[Dovecot] Dovecot Version Numbers - Let's drop the Alpha?

[Raymond Lillard]

Jack Bailey wrote:
> Cedric Puddy wrote:
> 
>> My experience is that the daemon performs much better than "alpha"
>> would ordinarily indicate.

Absolutely true.

> and there's the nomenclature itself. "Alpha" means (or at least it used 
> to mean) testing under control of the developers. "Beta" means testing 
> under control of the users. It looks like we all agree that Dovecot is 
> beyond both.

Well sorta ...  In my experience with s/w development, I have
used the alpha designation to mean that the code was fairly
stable and usable, but not necessarily feature complete.  Alpha
code is only made available to selected and highly skilled
users who can provide detailed bug reports including a test case
that exposes the bug.

Beta code is deemed feature complete and ready for wider
testing.  Beta code should not need any great thrashing of
internals to be ready for release, however if needed, do it.
Beta s/w should also include at least a completed first-draft
of the user documentation.

After an appropriate period of beta-testing and a final draft
of the user documentation, a series of release candidates is
started.  When an appropriate time period has passed w/o any
patches, the s/w is formally released.

On more occasions that I like to admit, I have been forced
by scheduling requirements from senior management to fudge
the above rules a bit.  C'est guerre.

In the case of Dovecot, there seems to be aspects of the
project that fit all of the above coding stages.

My (unsolicited) advice to Timo would be to create a branch
tag to the project as soon as practical and apply the bug fixes
to the branch as needed, as well as to HEAD.  Feature development
can continue on HEAD as planned.  These new features would
appear in later releases such as 1.(n+1), etc...

As soon as the bug rate to the branch tapers off, create the
1.0 release tarball from the branch tag.  This method is roughly
the same as the OpenBSD development team uses and it clearly
works rather well.  Nobody, in my experience, produces a
tighter and cleaner software product than OpenBSD in both
the free or commercial world.

The key here is to create a branch that will only have bug
fixes applied which is separate from on-going development.
A significant portion of the instability seen in Dovecot
is to the continuing development.  These two activities
need to be separated to achieve the desired stability in
the released code.

I have been using Dovecot for the last 3 years and have
rarely had any trouble with it even though it has been been
labeled -test and -alpha.  My thanks to Timo and his merry
elves for a filling need in the open source community.
IMHO, Dovecot is already best-of-breed.

It is testimony to the competence of Timo and crew that
Dovecot is rather stable.  Separating bug-fixing from
feature development can make Dovecot uncommonly so.

Just my $0.02
Ray

PS  Long diatribes happen when one has free time on a
     cold rainy Saturday night.