Release philosophy (was: Re: Miscellaneous Things)

[Hans Ronne]

>> How about if, as soon as all of the serious bugs such as instant crashes
>> are fixed, we put out a release candidate (7.5rc1)?  Then we can wait
>> for anyone to report additional bugs, and we fix them, put out a new
>> release candidate (7.5rc2), etc.?  Then when a release candidate has
>> been out for a while (maybe a week or two) with no new bug reports, we
>> release 7.5.
>
>I feel the same can be accomplished by packaging known good CVS
>snapshots. Perhaps the only thing missing from the picture is to
>announce the availability of the these snapshots.
>
>I personally think we should release 7.5 when it's ready. Maybe
>the documentation doesn't need to be brought entirely up to date
>before a release. But I don't think there should be any
>regressions from 7.4.1 as far as "make check" is concerned. And we
>are still getting closer to having much more intelligent transport
>behavior; I would want to wait until that improvement is in and
>working properl; it would be a boost to AI play, IMO.
>
>> seems to work very nicely for them.  And if nothing else, it becomes
>> clear to anyone who's paying attention that Xconq is *not* a dead
>> project.
>
>Perhaps it would not appear dead anymore, but it could earn a
>reputation as being quite buggy and needing lots of work.

I agree with Eric. Let's not rush things when we are almost done. Lincoln
has a good point, however, in that more snapshots/release candidates are
needed in the final phase before a release. I think Eric's Windows
Installers and rpm packages can do this job, but they could perhaps be more
frequent.

As for the Mac, I had already prepared complete packages two weeks ago, but
when the synch error hit us I postponed their release for precisely the
reason stated by Eric: that it could earn Xconq a reputation as being buggy
and unfinished. With the synch error now being fixed, even though it is
only a temporary hack, I will give this another try.

Hans