On Sat, 20 Jun 1998, Dean Brooks wrote:
> Does Exim go through periods of "no new features" where bug fixes
> are made until the release can become "stable"? I guess I'm hoping
> for something similar to the Apache project where features are added
> in one large development time period and then features are frozen
> while bugs are fixed. The result is that the "release" versions of
> Apache are amazingly solid and bug free.
Before I make a "proper" release (i.e. with updated documentation), I
put out a release for testing while I work on the documentation. This
typically takes about a month. During that time I make only bug-fix
changes to the code. I guess these are beta releases.
After the "proper" release I do not add new features for a while (a few
weeks) while it settles down. On past form, this has resulted in one or
two further bug-fix releases (e.g. 1.90->1.91->1.92). After a few weeks
I start developing again.
> Having read _every_ single entry in the ChangeLog (which took quite
> a while), I really never found a point where there was a "stable"
> release that had features frozen and all known bugs fixed.
I usually fix all known bugs before any release. In fact, I try to fix
bugs as soon as I learn about them; the fix is then in the development
source and is automatically in the next release. The only exceptions
would be really trivial problems for which there is an obvious
workaround.
> 1.92 looked stable, but then I see that 1.927 alpha fixed a bunch of
> problems from 1.92 that handled split spool directories. So now 1.927 alpha
> looks like the best choice, but I'm concerned about using alpha software.
The split spool directory bug was only discovered after the 1.92 release
had been out for quite some time. It is a performance bug rather than a
features bug. The current alpha is 1.929.
> The ideal situation would be to freeze new features at some point
> in the near future and only fix outstanding bugs. Exim would continue
> to become more and more stable, and at some point it could become
> the baseline for future development.
That is sort of what happens, but only for a few weeks. If a majority of
Exim users want me to operate like that on longer timescales, I
certainly could (and it would give me time to work on the introductory
documentation). However, so far people have wanted many new features by
yesterday, so this has not been a realistic approach.
On Sat, 20 Jun 1998, Steve Lamb wrote:
> The ideal situation would be to model the development of the kernel, the
> Debian project and others. Have two concurrant versions. One is a "Stable"
> release which only gets bug fixes applied to it, the other the "unstable" or
> "development" model where new features are introduced.
The disadvantage of this is that you have to fix bugs that exist in both
versions twice. I seem to recall several incidents in the last 25 years
or so of new OS releases (from various vendors who shall remain
nameless) re-introducing bugs that had been fixed in previous releases -
because the fixes hadn't been propagated into the development versions.
When I am the sole person working on a piece of software (which is the
case for Exim) I prefer to have just one development source which gets
all the bug fixes and new features applied to it. Then there is less
likelihood of anything getting lost. (I accept that in larger projects
and when there are several people working on something, things are very
different and you have to operate in a different way.)
--
Philip Hazel University Computing Service,
P.Hazel@??? New Museums Site, Cambridge CB2 3QG,
ph10@??? (sic) England. Phone: +44 1223 334714
--
*** Exim information can be found at
http://www.exim.org/ ***
