directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: Release naming. (Was: Re: locking issue with apacheds 0.9 - URGENT !!!)
Date Fri, 07 Jul 2006 19:44:58 GMT
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"

For us a release candidate is one where there is a freeze on new 
features additions.  The odd 0.9 branch was for feature additions.  Just 
like the linux 1.3 or 2.1 branches were feature addition branches.

So when we freeze the additions of new branches we start preparing for 
releasing the first stable branch release.  In between 0.9.X and 1.0 
releases are the 1.0 RCs.

1.0 RC like you say can be deemed good to release as 1.0.  We intended 
0.9.5 to be a RC for 1.0 and hoped it would go out the door as a 1.0 but 
we found problems.

Basically I think our idea of a RC is the same.  The difference is we're 
finding many more issues than we though so the period for it is long.

I do not think we should plan release candidates RC5 etc.  If a release 
candidate is not good enough then there will be another with the right 
fixes until we get to the quality we want.

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

We did rename what was to be released as 0.9.5 to 1.0-RC1.  We just did 
not release 0.9.5. I think its a matter of semantics right?

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

Our problem is when we froze new features and readied ourselves for a 
1.0 we found too many bugs.  So the RC candidates kept going on and on. 
  It should have taken less time but this is what we have so we will 
keep solving bugs and issues as users test this code.

Key thing to point out with a RC series is as soon as one is good enough 
the series ends.  Also RC series get better in quality with each release 
since we find and solve more bugs without introducing new ones 
(hopefully).  This is to a large extent true because we do not add new 
features that change the code in major ways.

If we went back to 0.9 (odd hence feature introduction branch) then we 
could not say the next release *should* be of higher quality and all 
feature additions have been frozen.

BTW for the 1.0 branch we merely intend to do bug fixes.  1.1 will start 
off introducing new features somewhat destabilizing the server.  Then 
1.2 will stabilize and so on.

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

I agree with E here.

>> - at a point, we successfully closed all the major issues : time for a 
>> new RC

I agree the RC series should not be planned.  They are there to 
stabilize the code for the first GA release of a branch.  Once there is 
a RC that is tested and deemed stable enough we can release 1.0 or just 
rename it to 1.0.

However there have been situations where we released 1.0-RC3 for example 
in advance for user testing before solving all bugs.  We knew we were 
going to have to do an RC4 because RC3 was not good enough.  This was 
because we wanted to get something out for users to confirm fixes to 
bugs.  Not a perfect situation I admit it.  The beta designator might be 
a good idea here but we really thought we'd be done when we started this 
RC series with one at most two candidates.

Really I think it's all semantics.  Our release candidates are official 
releases because we want the user community to get their hands on an 
official release so they can tell us we are GA worthy.

So instead of riping out a RC tarball and asking peeps to test it for a 
week we tag and release calling it a RC.  Then we wait for bugs to come 
in.  If there are not many bugs within a certain time (2-3 months) then 
we can release 1.0 GA.

See it's just about time periods and semantics.  Most people are used to 
the RC tarball with a notice to test for a few days before doing a GA 
release.  We're a bit more spartan about it because we're building 
server side software that needs serious dependability.  It's not a 
client side application that can work OK with a few bugs and 
workarounds.  My goal is not to simplify the nature of client side 
verses server side software.  However for example a memory leak in a 
client side program run occasionally will not amplify into a nightmare 
as does a memory leak in a process that might run for months.  These 
kinds of long running problems take months to figure out.  You can't 
just run the server and find these hairy bugs some of which are often MT 
in nature.

So take the normal 1 week process you are used to for RCs and stretch it 
out to 2-3 months with an SVN tag for the RC.  Then you arrive at our 

Crazy? Perhaps.  But we want 1.0 to be rock solid.  When we put it out 
there people should have confidence in the software.


View raw message