Re:Rails 3.0: Release candidate
by dhh on Monday July 26, 2010 @06:21PM
(#1549528)
Because we're not going to change the interface to make the internals faster. And we might as well spend the time that the RC is out there looking for bugs to make things faster as well.
[ Parent
| on HN ]
This may be a source of confusion. In most circles, release candidate signifies that this should be the final release, and will only be changed if new bugs emerge.
The exact meaning of terms like "beta" is subjective, but "release candidate" has the it right there in the name.
It's not a release candidate if you literally state that it is not a candidate for release.
Exactly. Not to mention if you know you're going to be working on it, there's always the chance new bugs can emerge as a result.
If I install the final version I'd expect that means it's the exact same version as the most recent release candidate and no critical bugs were found during that period. Not the most recent release candidate, plus a bunch of tweaks that were made while everyone was testing. And if you're already assuming there will be another release candidate before a final, then this isn't a release candidate.
s/Most/All/. I've never heard of a release candidate meaning anything else, it's something you'll release as-is with a non-rc version unless critical bugs emerge. This is a beta, not a RC.
Think of it as a Rework Candidate then.
From a broader perspective, I expect that the Rails versioning nomenclature will conform to SemVer (http://semver.org/). Yesterday, wycats tweeted that he believes strongly in SemVer, in regards to Bundler.