directory-dev mailing list archives

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

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
> bugs".

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,

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
> > 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.

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 [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)

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

> --
> Trygve

Emmanuel Lécharny

View raw message