rst at ai
Apr 14, 1995, 12:49 PM
Post #21 of 24
From: Rob Hartill <hartill [at] ooo>
Date: Fri, 14 Apr 95 10:10:30 MDT
> It depends what you want to be the beta release candidate --- if
> 0.5.1 *is* beta 1, then throwing code which will need to be fine-tuned
> later into 0.6 is not a problem. On the other hand, if 0.6 is going to
> be our first beta release, then we probably shouldn't have stuff in it
> which has known problems.
that depends on whether they are "problems" or "improvements"
I'd say things like name changes were improvements, whereas
patches which broke existing features were problems.
If the objections only appear a few hours before the planned rebuild, the
patch contibutor has no time to make changes, and he ends up chasing a
moving target, as Andy put it.
I'm not sure you got the point of my objections above --- most of the
time, I wouldn't have any objections to throwing in things which seem
to be a good idea, even if they aren't quite fully baked, because most
of the time, we can just slip a fix for any problems that arise into
the next week's internal release.
However, if we are going to be *publically* releasing 0.6, then
circumstances are different --- fixing the problems means either
delaying the release another week, or shipping code with bugs. So,
it's just because we are closing to a public release that I'm