On 7/15/06, David Anderson <david.anderson@calixo.net> wrote:
> Justin's understanding of an RC is that when we release one, we are
> saying "Please test this, and we'll take your reports into account
> when rolling the final release". Specifically, the contract is much
> more informal, and lets us release something in a state that we know
> is unfit for final release, because we are just looking for wider
> testing by downstream developers. Under that contract, we can release
> RC2 once we have the correct number of sigs.
It's not whether it's purposely unfit for final release - but it is
that we are looking for wider testing by downstream developers and
other users that wouldn't try a checkout. From our perspective, the
RC should be feature-complete: this is why it's not an alpha or a
beta: the only subsequent changes should be bug fixes, but no new APIs
or features should land after the RC is cut.
The point of a RC, to me, has been to allow those people to try out
the new APIs in their own programs and ensure that it works as
expected. It also allows for users on more platforms and setups than
we would ordinarily receive from just the committers or folks on the
mailing list. It is also an opportunity to find packaging bugs (like
what version of autoconf to use!) before we go final. If we find an
error in one of those new APIs, we have a chance to fix them before we
go final and commit to that API for the rest of eternity. We can also
smooth out packaging issues in between release candidates.
I do think the purpose of a RC changes as we produce more of them in a
series. The 'early' ones can be released with known issues that we'll
fix up before the next RC; but the last one that we put out should
have no issues reported on list. But, in my mind, it's certainly okay
to issue an 'early' RC that has *some* known issues that we fix up
before the next RC. So, there's no need to have each RC be perfect
and to have that hold up the release candidate being tested in other
areas. We're not perfect and it's going to be downright impossible
for us to cut a RC on the first shot that is perfect.
Plus, a strong reason why we have a RC at all is to avoid burning the
.0 in the release sequence. This way we know that the .0 has been
tested to the best of our abilities before making it public. But,
it's perfectly okay to me if we burn through RCs - but we don't need
to re-roll on *each* bug we find. We put the RC out there and let all
of the other reports come in; then in another two weeks, we roll
another RC with the collection of bug fixes that we've incorporated
into the tree. But, to expect, rc2 to be final immediately isn't
justified until we've gotten external feedback of at least four weeks.
BTW, I think the soak/stabilization discussion in HACKING is the most
relevant here.
My $.02. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 15 18:42:32 2006