Michael W Thelen wrote:
> Ben Reser wrote:
>
>> Well just waiting is a good way of ensuring that bugs that are
>> exceedingly annoying to you end up getting in a release. A lot of us
>> use the software, but most of the developers don't really use the ls
>> command. Not trying to lay blame here. Just pointing out that if we're
>> going to shorten the soak time (which we did becasue many people felt a
>> month was too long), users who care about having clean releases need to
>> be proactive in testing the release for features that matter to them.
>
>
> For what it's worth, I've been testing the RCs but was on vacation
> without Internet access for the week between RC4 and 1.1.0. (until just
> yesterday actually, and still trying to catch up on the email :)
>
> Maybe the seriousness of this issue would suggest that although a month
> may be too long for a resoak, a week may be too short? Would two weeks
> perhaps be better?
What we do for CUPS is require a minimum of two weeks between a
release candidate and the final (production) release, and we
require that any priority 4 or 5 STRs (software trouble reports,
the equivalent of a Subversion issue) be resolved before we do a
production release.
This has worked well for us over the last couple years we have been
doing it. Before then we didn't do release candidates and often had
to do a patch release to fix simple errors we didn't catch on our
own build systems... Some quick analysis showed that we generally
found and fixed these issues within a couple weeks, so the 2 week
release candidate rule was born (even for security fixes).
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Printing Software for UNIX http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 5 14:26:48 2004