Emmanuel Lecharny wrote:
Hi Trygve,
On 7/7/06, *Trygve Laugstøl* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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"
--
Trygve
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
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
releases.
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.
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
bugs". That is at least the impression I'm getting from what I've
gathered from the list. 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.
- 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*.
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)
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.
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.
If you take a look at [1] 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)
[1]: http://directory.apache.org/subprojects/apacheds/releases.html
--
Trygve
