[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: the logistics of beta release management

Hash: SHA1

On Thu, 9 Jan 2003 10:19:02 -0500 (EST), Robert P. J. Day wrote:

>   probably slightly off-topic, and not a specific RH question
> so much as a general beta software issue.  for those who are
> software developers and themselves release beta versions for
> testing, i'm curious:
> 1) if you release more than one beta in a row, what's your threshold
>    for deciding when it's time for a next beta?  clearly, you 
>    might still have bugs coming in for the current beta, but at
>    some point, after a certain amount of patching/fixing has
>    been done, you eventually have to make a decision to release
>    the new and improved version.  what factors into that decision?

 - the number and volume of modifications/additions since the
   previous beta
 - the number of severe problems which blocked users from testing
   the previous beta or important parts of it

 - the number and type of changes to crucial core components

 - the number of bug reports for the previous beta (some potential
   beta testers don't touch a first beta and prefer testing of what
   is more like a preview or even a bit like a release candidate)

 - figures on how much some components might have been tested
   (includes invalid bug reports, questions and RFEs)
 - the release schedule ;) and time constraints (contracts)

> 2) once you release a new version, how completely do you ignore
>    the previous beta?  given that it's not an official release and
>    you have no obligation to provide support for it, are you 
>    at all interested in even *getting* feedback for the 
>    now-obsolete beta? do you even want anyone testing it 
>    any more?  and is so, why?

Of course. Bugs found in the previous beta may still be reproducible
in subsequent beta releases.

> 3) once the new beta is out, what do you do with the unresolved
>    bug reports from the previous beta?

See 2), they get checked for reproducibility and compared with
changelog entries for any fixes that were applied during normal
software development and maintenance (without a prior bug report).

- -- 
Version: GnuPG v1.0.7 (GNU/Linux)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]