

Don't use release candidates - sciurus
http://rwmj.wordpress.com/2011/07/15/dont-use-release-candidates-use-stable-branches-instead/

======
groby_b
Having an RC doesn't mean you abandon development on it. What exactly is the
difference between calling it 'RC' and 'stable branch'?

Both get released to users, both get changes backported.

Except with RC, you're honest. It's a _candidate_ for a full release. If you
call it "stable", you're misrepresenting facts. You're not stable. You
wouldn't even know, since you had no widespread testing on it.

------
glimcat
It depends heavily on the team's culture. Are we talking a team who uses beta
as code for not fully supported yet or a team whose stable releases aren't
very?

------
wccrawford
"In 5 days time I will fork whatever we have in development and I will declare
it stable branch, release 1.12.0. That’s not going to be a stable version, and
we don’t pretend it is."

... Except that you've called it stable, so you -are- pretending it is.

The only thing I would get from such a naming convention is the sense that you
don't actually care about stability, since you call things stable when you
know they aren't.

Release Candidates, on the other hand, show you are trying to be stable but
realistic about the possibility of showstopper bugs.

------
geuis
I can't disagree with this more.

1) Most bigger open source projects have a core team. Think about the jQuery
team for example. Often, the release candidates are intended for the core
team, not the general user.

2) General users of a particular project generally know better than to use
RC's in production. They might not be part of the core team, and unless they
are going after a specific feature or bug, will ignore RC's and go with latest
stable releases.

3) Release Candidates are supposed to be feature complete. If a user needs to
start testing their applications against new features being introduced can
usually do so early against Release Candidates. So contrary to the author's
statement, indeed you can expect 3rd party engineers doing those kinds of
integration tests to file bugs when things aren't working right. I've
certainly done it, and I imagine many devs on HN have too.

4) If you want to look at a situation where you _don't_ get Release
Candidates, remember how often Facebook changed and broke Facebook Connect
over the last couple years. It is _not_ fun having to re-architect your FB
integration 3x within a matter of a few months because they just pushed code
live with little or no warning.

