This project is archived and is in readonly mode.
Release Candidate should mean feature freeze
Reported by Trevor Turk | July 29th, 2010 @ 04:28 PM
Shouldn't publishing a "release candidate" (RC) mean freezing the development of new features and focusing on the arbitrage of critical, show-stopping bugs in the aim of a speedy "official" release?
From Wikipedia:
http://en.wikipedia.org/wiki/Software_release_life_cycle#Release_ca...
The term release candidate (RC) refers to a version with potential to be a final product, ready to release unless fatal bugs emerge. In this stage of product stabilization, all product features have been designed, coded and tested through one or more beta cycles with no known showstopper-class bug.
I've been watching the development of Rails and Bundler in anticipation of a Rails RC so that I could start upgrading and testing my existing Rails apps in earnest. I'd been testing with beta releases previously, but with 4 beta releases of Rails and 10 beta releases of Bundler, it became too difficult for me to track.
I expected to see some last minute bug fixes after these RCs, but some of the commits since the RC tags look like new features to me:
http://github.com/rails/rails/compare/v3.0.0_RC...master
http://github.com/carlhuda/bundler/compare/1.0.0.rc.1...master
...and so I'm wondering if I should just wait for an "official" release before upgrading and testing in earnest.
My fear is that there are other early adopter / beta testers that have been put off by this as well, and I think that losing this kind of "in the wild" testing may reduce the quality of "official" releases and eventually reduce adoption in general.
Comments and changes to this ticket
-
Yehuda Katz (wycats) July 29th, 2010 @ 04:48 PM
- Importance changed from “” to “Low”
Trevor,
I'll only speak to bundler here. We released an RC build of bundler when we honestly felt like there were no more showstopper bugs, and it felt plausible to release. There were a couple of features (like the --production flag), that we planned to add in 1.1. After doing so, we got a torrent of people who used bundler for the first time and were extremely confused by certain flags (like --disable-shared-gems).
Specifically, the correct practices for deploying bundler are somewhat different than using it in development, and it takes a few (documented) flags to get it working smoothly on deploy. Because of the amount of bug reports we received that could be resolved by providing a clearer default path on deployment, we took the plunge and added the feature.
Specifically with regard to --disable-shared-gems, the option was mostly an internal option that switched off using locally installed gems as a source during installation time, but the name implied that it resulted in complete isolation. People, for instance, were doing
bundle install --disable-shared-gemsand expecting it to result in isolation, when it was actually a nonsense incantation that was just causing pain.When we looked at all the uses, we realized that people either install to their system (and therefore don't care about isolation) or are installing to a local directory (and therefore do care about isolation). We removed the option, clearly warning users who are still using it that it can be safely removed.
-
Trevor Turk July 29th, 2010 @ 05:12 PM
Thanks for the reply, and I'm glad to hear you say all of that.
Please feel free to close this ticket -- I just wanted to make sure we had the same idea of what a release candidate is supposed to be, and I sounds like we do.
Thanks!
-
Neeraj Singh July 29th, 2010 @ 05:53 PM
- State changed from “new” to “resolved”
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
<h2 style="font-size: 14px">Tickets have moved to Github</h2>
The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>
Jeremy Kemper
Neeraj Singh
Trevor Turk
Yehuda Katz (wycats)