Rails 3.0: Release candidate | Hacker News Reader

Rails 3.0: Release candidate

weblog.rubyonrails.org

135 pointsmrduncan46 comments

"We’ll be making sure we get performance of Active Record back to at least 2.3 levels before release." Why call it a Release Candidate if you still plan on tweak more stuff?

I don't think you are supposed to question DHH or what his name is.

Wow, ok. It was an attempt at humor. So now my question is is HN not the place for that? Or do HN folks generally get behind RoR? Or...do I just need to be more thoughtful and not thoughtless in my postings?

Help me be a better HN commentator, please.

If you get down-modded to 0, then you know you did something wrong. Humor is typically hit or miss, sometimes it kills, sometimes it doesn't. That being said, it is an online community and standard mob-rule still applies. I wouldn't dwell on a -4 too much (especially if no one will even comment to tell you why they down-modded). It happens, and no you're not a bad person ;-)

Yes, and it is my impression that the downmodding has become very aggressive recently. It's not for rude posts only anymore. Just looking at the above poster: he adds a polite request for explanations to improve his posting, and yet his reply gets brought down.

Agreed * 100

Humor is often OK. I suspect the problem here is that your comment can be taken in an antagonistic tone that many people have in regards to DHH and the 37signals philosophy. That sort of tone is generally not accepted here, especially as a one-liner without substance.

I read that as "that sort of tone is generally not accepted here in regards to the 37signals philosophy."

It was meant as that sort of tone is generally not accepted toward anyone/anything, especially as a one-liner because it doesn't add anything to the discussion. It was probably perceived that way because there are many people that have that sort of attitude toward DHH and 37signals. So any intent of humor was lost.

It has nothing to do with agreement or disagreement with their philosophy.

Okay, I get that. It really didn't bring anything to the table. I will remember that. It wasn't meant to be antagonistic though. Just for the record.

In other words, this isn't reddit.

My point goes deeper - reddit hates RoR. Mention ruby and you will be trampled.

The OP is seemingly negative on Ruby (which is cleared up through subsequent comments) and he gets trampled. When I say "this isn't reddit" I mean, there isn't the same RoR hatred here that one notices there. That's all.

About a year ago, yes, that would have been good, but HN has sort of been overrun by a gang of douche bags since then, so no, try not to be funny.

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.

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.

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.

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.

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.

I suspect this release is in response to some of the uproar (http://news.ycombinator.com/item?id=1545773, albeit dead) on the Rails list about the lack of a release and general lack of communication between the core team and the community regarding when a release might be expected.

Heh, if only it was that easy to get a release of Rails to happen! I'd use that more often myself.

This release happened because we have a candidate that's close enough to release that we wanted to get it out.

For new RoR programmers, is it recommended to just start in with Rails 3, or stick with Rails 2 until Rails 3 "stabilizes"? There are a bunch of Rails 3 books out there; do they generally line up well with this release candidate, or are they full of old information that a new RoR programmer would stumble upon and not understand how to fix?

[EDIT] The three books I saw available that specifically mention Rails 3 in the title are available for pre-order, so hopefully they will be pretty up-to-date.

I think it depends on what you're doing. If you're learning Rails just to learn it, go with Rails 3. If you're being asked to spec a Rails project, go with 2.3.8. Rails 3 isn't done cooking yet, and may potentially shift under you while you attempt to complete a project under a deadline while learning the stack - not a great choice, IMO.

Rails 3 is now done cooking from a feature perspective. That's why this release is a release candidate, not a beta or alpha.

Rails 3 is the way to go for new projects.

I got "rails 3 way" and "agile rails 4.ed". rails3way is pretty much a complete rewrite; its only 266 pages filled so far, but looks good. Agile rails is more finished than rails3way. They are both pretty good books, but if you want more of a "completed" book, agile seems to be the one closer to that. I'm learning RoR from scratch too. The recommended setup is to use ruby 1.9.2. Your first question really depends on what is your intention. If your primary focus is for job hunting, 2 may be the way to go. If you're trying to build something, I don't see much drawbacks (yet) on going to 3.

Go to Rails 3, a lot of the ways of doing things in 2.X will be deprecated in 3.1 and removed in 3.2, so just save yourself the hassle. Rails 3 also cleans up a tremendous amount of code and removes a lot of the 'obtrusive' Javascript from your views.

As far as 1.9.2, if you plan to do deployment (Even for testing) any time soon on Heroku (the coolest, if not the best hosting solution for Rails) then you may want to kick back to 1.8.7, because Heroku won't support 1.9.2 until a final is released.

I would jump right in to Rails 3. It's pretty great right now, and it's only going to get better.

The most up-to-date book is the free Rails Tutorial http://railstutorial.org, which will be updated to Rails 3 soon after it's final is released.

If you have an older book using an older version of rails, DON'T use Rails 3, use the version used in your book (DHH mentioned this on an episode of coderpath http://coderpath.com/posts/1)

There's actually a semi-secret version of the Ruby on Rails Tutorial book already updated for Rails 3.0.0.rc:

http://railstutorial.org/book?version=3.0.0.rc

Shhh... Don't tell anyone! :-)

(The official release of the Ruby on Rails 3 Tutorial book should happen some time in the next couple weeks, probably slightly ahead of the official Rails 3.0 release. Of course, the tutorial will also be updated after Rails 3.0 final drops.)

Now I have to start the tutorial all over again...but thanks! This should be a lot easier than looking up for myself how Rspec 2 works and so forth.

Just so you know, Rails 3 RC plus all the associated dependencies with rspec now core dump on integration ('requests') tests even though controller testing works fine. It looks like there is a webrat/rspec usage issue. I assume they'll get it fixed in a few days.

I'm glad to know it's not just me. The tutorial book pins RSpec down to 2.0.0.beta.18 for just this reason. (It looks like 2.0.0.beta.19 is the one that has the problem.) Of course, I'll update the tutorial with the latest RSpec version once they fix this issue.

Here's the rspec ticket to keep an eye on:

http://github.com/rspec/rspec-rails/issues#issue/140

Thank you—this is very helpful.

While you're here :) I wanted to say that your book/tutorial is really well done. I was working through the 2.0 version and simply figuring out what needed to happen for 3.0. Thanks for the link to the 3.0 version. I'll let you know if I any problems or confusing parts.

The list of changes in Rails 3.0 is fairly approachable if you understand the basics of Rails. I'd recommend taking a look for yourself - http://guides.rails.info/3_0_release_notes.html

As far as whether 2.3 or 3.0 makes the most sense at this point, it depends. Personally, I have been working on a brand new project that I started with 3.0 beta 1 and haven't ran into any major headaches. That said, since you're new there is a lot more information out there regarding 2.3 (be careful, some is much older).

To give you some better advice, why are you getting into Rails? Are you trying to get a project started/out the door/etc, or simply looking to learn it because it looks interesting/fun?

I think now would be an excellent time to jump into 3.0. So much has changed since 2.x, practically every Rails developer, new and old, will be blogging, tweeting, debugging and asking and answering questions on StackOverflow about Rails 3, you'd be daft to lag behind and miss the opportunity.

other than "So much has changed since 2.x," I personally think it would be great for you explain why "practically every Rails Developer" should jump in to 3.0.

Your comment is a given, right?, but other than to state the obvious, I'm curious as to your personal reasonings regarding this release.

The biggest two for me are massive performance increases as well as unobtrusive javascript.

Now, I haven't done any specific benchmarking with my apps yet, but the upgrade from ree to 1.9.2 seems to be fairly large from every benchmark I've seen, as well as Rails 3 itself becoming faster, due to the Merb influence.

Unobtrusive JS is awesome; I never used Rails javascript helper stuff because I prefer jQuery to Prototype, and just wrote all of that stuff by hand. Now I can actually use helpers.

Full HTML5 support is also nice, though I guess haml was already doing that for me.

Why wouldn't you? It's faster, it'll eventually have more support from the community, and has tons of improvements which should help with your productivity.

I haven't had a look at 3.0 yet. What's the effort like to upgrade? I have this suspicion that it's basically going to be a major rewrite for most of my projects with all the new apis and deprecation. It's almost as if it were a completely separate project that offered some degree of Rails compatibility to help people transition. However, that's the impression I get from reading things - how is it in practice for those who have updated significant code bases?

The core Rails APIs are mostly the same, though you'll have to basically rewrite a couple of files in config/. I'm currently porting a moderately large application from 2.3, and few of the remaining unit test failures have anything to do with the Rails core.

Your biggest problem will be that a number of third-party gems have been heavily updated for ActiveSupport 3.0, including RSpec, Devise and Mongoid, and these may cause more headaches than Rails itself. Figure a few days of updating stuff and staring at unit test failures if you rely heavily on these gems.

Of course, all bets are off if you use a lot of dodgy, unmaintained gems that heavily monkey-patch Rails. We have a pretty strict policy against using dubious minor gems that stick their fingers deep inside Rails, after some bad experiences over the past couple of years.

You've got to be careful with Ruby versions.

Rails 3 runs on 1.8.7 and 1.9.2.

My machine before was running on 1.8.6 and 1.9.1 (okay, I'm lazy!), but luckily RVM simplified the upgrade for me.

If you are still running on 1.8.6, it's something to bear in mind :).

What's the upgrade path like from Merb?

Quite simple, I rewrote a medium sized app in about a day, and actually fixed a few things too.

I found it really easy to upgrade from either rails 2.3.x or merb.

Reply on news.ycombinator.com