3 ms·

Don't use release candidates

8 points by sciurus 15y ago

glimcat 15y ago
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 15y ago
"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 15y ago
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.
groby_b 15y ago
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.

8 points by sciurus 15y ago

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 15y ago

"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 15y ago

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.

groby_b 15y ago

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.