Hacker News new | ask | show | jobs
by eric-hu 4840 days ago
If you have a large application, upgrading it will not be trivial. Suppose your company spent several months developing their app on Rails 3.1.x. Rails 3.2.x comes out and some gems you're using break when you try the upgrade. Your company still has other bugs to fix and features to produce, so they switch back to 3.1.x and just make a note to check compatibilities periodically.

The 3 versions patched are not forks. They're just different versions of Rails. In three years, they'll probably still support about 3 versions and drop support for older versions once they hit a certain age.
2 comments
steveklabnik 4840 days ago
> In three years, they'll probably still support about 3 versions and drop support for older versions once they hit a certain age.

You can find the exact maintenance policy here: http://weblog.rubyonrails.org/2013/2/24/maintenance-policy-f...

link
halostatue 4840 days ago
Spot on. We were still running 3.0 a couple of months ago when a vulnerability came out with the indication that this would be the last patch version of 3.0. We made it a point to upgrade to Rails 3.1 right then—it took about two days, which we didn't really have, but we needed to do. Since then, we've taken another 3-4 days over the last couple of months to upgrade to 3.2 (and start using features that will make a migration to 4.0 much easier).
link
eric-hu 4840 days ago
You mind if I ask what 3.2 features will make 4.0 migration easier? I haven't kept up with the 4.0 changes
link
steveklabnik 4839 days ago
We offer strong_paramters as a gem for Rails 3.2 apps, and generally tell anyone doing greenfield development to start with it to make the transition easier, and because it's simply better.

You can check the upgrading guide for more details about what's changed, and a third party is selling an ebook that has a ton of good info as well.

link
halostatue 4839 days ago
steveklabnik has it spot on. We're starting to move toward strong_parameters; we've got it as a gem, but we haven't yet made the change to entirely turn off attr_accessible.

We're also starting to use verb-matchers in the routes file, but that's going to be a bit more painful to deal with…

link