Trygve Laugstøl wrote:
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"
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
scheme.
Crazy? Perhaps. But we want 1.0 to be rock solid. When we put it out
there people should have confidence in the software.
Alex
