Hi Trygve,

On 7/7/06, Trygve Laugstřl <trygvis@apache.org> wrote:
If you have a RC that is not of final release quality you should really
use another name than RC. If it really is that unstable it should still
be marked as an unstable release.

Release candidates usually means that "This is what I would like to
release, please test it and if everything is ok we'll rename it to 1.0"


RC are really suposed to be release candidate, not final. A RC can be found unstable because a bug has been found in it. We are not igniring major bugs, and we really try to cut a new RC when all the current RC major bugs are closed. If someone download a RC, and found a bug, perfect : we are on our way to a new RC.

The problem is that we may invent new names like GA, or whatever, but it won't change the process :
- while all the major functionnalities are not into the product, it's a 0.X version
- when we have gathered all the makor functions into the product, and when all the running major bugs are fixed, we deliver a 1.0-RC1
- then, users simply use it a different way we do. They fill JIRAs, attach patches, and we fix them. We don't add more features, we just fix minor ones in the mean time.
- at a point, we successfully closed all the major issues : time for a new RC
- after a few iterations, we may think that the version is stable enough to be labeled 1.0. It takes time because it's not just a question of code, but mainly documentation, minor fixes, performances tests, regression tests, and so on.

FYI, RC3 was supposed to be stable enough 3 weeks ago, then while doing intensive tests, we found a major performance problem, and a major memory leak (not likeley to be found before you insert more than 100 000 entries). Call it unstable, but only because the unstability factor has popup.

So I think we comply with the "please test it" spirit. And be sure that the next RC (RC4) won't be the last one. We have a RC5 in mind because we need to improve the documentation, and because many little bugs need to be patched (an exemple of what is a little bug : if you use the LdifReader class, it won't accept a file which does not end with two \n : this is a bug, but it's not blocking. Users shiuld only be informed on this limitation. We may differ the fix until the next RC)

I hope my opinion is shared, I also may be totally wrong, but, however, this is always the same MTBF problem :
 * a program is correct until the next found bug



Emmanuel Lécharny