This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: Release philosophy (was: Re: Miscellaneous Things)
- From: Eric McDonald <mcdonald at phy dot cmich dot edu>
- To: Lincoln Peters <sampln at sbcglobal dot net>
- Cc: Stan Shebs <shebs at apple dot com>,Xconq list <xconq7 at sources dot redhat dot com>
- Date: Thu, 4 Dec 2003 22:07:24 -0500 (EST)
- Subject: Re: Release philosophy (was: Re: Miscellaneous Things)
Hi Lincoln, Stan,
On Thu, 4 Dec 2003, Lincoln Peters wrote:
> On Thu, 2003-12-04 at 18:04, Stan Shebs wrote:
> > The most important way to get visibility is to "release early and often".
> > 7.5 doesn't have to be perfect, because only 5% of the audience will
> > take note of the announce anyway; but 10% will notice the 7.5.1
> > message, having been primed by the 7.5 release, and so forth. Since
> > there hasn't been a release in a long time, most people will assume
> > Xconq is a dead project and not even look to see what's up with it.
>
> 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.
Eric