On 7/7/06, Trygve Laugstøl <email@example.com> wrote:
Emmanuel Lecharny wrote:
> Hi Trygve,
> On 7/7/06, *Trygve Laugstøl* <firstname.lastname@example.org
> 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
I see that we have a rather different view on the meaning of the names
here, but normally that's when people start to deliver alpha and beta
This is not because we don't agree that I'm right :)
We don't have alpha and beta. Many Apache projects don't have alpha and beta. In fact, I don't think there is a common agreement on naming in the industry. What we have are usages, and it can change from each organization.
You are already using the Linux versioning with odd numbers beeing
unstable releases. But you seem to have skipped the part where they
rename the last odd release to a even version number when the odd branch
is concidered stable.
Welle, we haven't already reached this point :)
Usually an RC is a statement saying "This release should not contain any
major bugs and should be production quality." but you are now definining
it to "This release is supposed to be stable but it may still contain
I meant, minor bugs, and I defined what I called minor bug (cf my previous mail). All major bugs are to be closed before a new RC is released, definitively.
That is at least the impression I'm getting from what I've
gathered from the list.
Sorry about that :( We for sure have to improve our behavior, so thanks for this kind of feedback.
If this is not true I would have expected you go
to back to releasing 0.9 versions until the product is of release quality.
We really thought that 1.0-RC1 was stable enough to deserve this label. It has been used by Geronimo, James and a few other project before 1.0-RC1, without too much bad issues. At some point, you must take a chance, and hope you weren't too far from the target.
> - 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.
A RC should definitely include the entire package that's supposed to be
released, it is after all called a release *candidate*.
Well, if you consider Eclipse, they do have RC which don't contain all the final features. Again, I don't think that there is a consensus on such matter. For us - correct me if i'm wrong, guys - RCx is feature full, but may lack of documentation and minor bugs may be there. If a major bug is found in RCx, then a RCx+1 is released to avoid users of RCx being blocked.
> 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
> 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)
Again, how can you call something a release *candiate* if you do not
expect to release it? You should definitely go back to 0.9 or start
creting beta versions.
We expect to release it. A bug may not always be a show-stopper, as soon as the user know about it and that it's not blocking. We are not living in a perfect world, where products are delivered 1°°% bullet-proof, documentation ready, feature completed... Are we ? But that doesn't mean eithger that we consider half-finished work as perfect :) We do your best, we make choices. At the end, the user is the judge.
> 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
Everyone is entitled to a opinion of course, and each project define its
own naming schemes which is fine.
But when you do not have a public page describing the naming of the
releases and you naming that is commonly known to be stable you should
take a look at your own naming scheme.
Yeah, we may need to add a page on our - very crappy and limited - site...
If you take a look at  you will see that you have annouced the RC1
release (where are the other two releases) without saying anything about
this not beeing the (hopefully) last release before 1.0. The normal way
of trying out a RC candidate is to try to run it in either production or
a production-like environment, see if it works and report back any
results (positive or negative)
Nobody is perfect :) Thanks for pointing this out, we will try to improve our communication. Btw, we are welcoming any volounteer and engage them to join us and improve the whole quality of ADS, being the site, the documentation, the tests, the code, or even the release policy documentation :)