directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trygve Laugstøl <tryg...@apache.org>
Subject Release naming. (Was: Re: locking issue with apacheds 0.9 - URGENT !!!)
Date Fri, 07 Jul 2006 11:01:02 GMT
Emmanuel Lecharny wrote:
> 
> Hi Trygve,
> 
> On 7/7/06, *Trygve Laugstøl* <trygvis@apache.org 
> <mailto: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"
> 
>     --
>     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

Mime
View raw message