From what I saw on their Github page, the Rails development team has been releasing Release Candidate versions since May, and the most recent tag is v3.1.0.rc6.
I found many comments on Google about new features, but almost no critiques or experience tails.
So, are you using Rails 3.1 already? If so, in production environments? And also, what has been your experience? Are there any gems that absolutely won't work with Rails 3.1?
I appreciate any comments/opinions!
Here is git issues for Rails 3.1: Rails 3.1 issues
you can check that it near to final realease :). As for me I use Rails 3.1 in my work. And we have some projects already in production mode. As for gems, so I havent met gems that do not completely work with Rails 3.1. But anyway you should use most fresh version of your favourite gems or use completely new ones. So have a try on Rails 3.1 - it is stable and have many awesome new features.
Related
We have an application which is currently on Rails version 2.3.12 and Ruby version 1.8.7. We want to update our application to Rails 4.0 and Ruby 2.1.0. We have around 200 models and 150 controllers.
I would like to know how big an effort is it to undergo the upgrade process. Also can you provide steps which can be followed for the upgrade. Should we first upgrade Ruby and then Rails or vice-versa?
What you want to achieve is gonna be an epic effort. I can't provide you the step by step instructions because it's impossible to cover all the cases in a single answer.
I recommend to not upgrade Ruby and Rails in parallels, but in small steps.
The complexity of the upgrade itself is huge, but it's not impossible as long as you have a reasonable test coverage of you application. I really hope you have tests. If you don't, then you can't even think to start an upgrade like this and you first need to ensure a minimum coverage for the product.
My suggestion is to follow this roadmap
Upgrade Ruby from 1.8.7 to 1.9.3. Rails 2.3 is supposed to be compatible with Ruby 1.9 and you'll get the benefit of a more recent Ruby version. In fact, several gems have dropped support for Ruby 1.8.
Leave the app settle and run for a while, just to make sure you can find and fix incompatibilities. Every time you find an issue, reproduce it with a test, then fix it.
Upgrade Rails from 2.3 to 3.0.
Same as point 2.
Upgrade Rails from 3.0 to the latest 3.x version.
Same as point 2.
Upgrade Ruby from 1.9.3 to 2.0. The upgrade should be trivial.
Same as point 2.
Upgrade Rails from 3.x to the latest version
A few notes
The reason I suggested you to not upgrade from Rails 2.3 directly to 4, it's because it's almost impossible.
The reason I suggested you to not upgrade form Rails 2.3 directly to the latest 3.x, it's because from 3.0 to 3.x there is the asset pipeline new feature that is gonna cause you several headaches. It's better to handle this step separately and not in a big upgrade.
Ruby 1.9 handles encoding differently than Ruby 1.8. Rails 2.3 is not well prepared for this.
The issues often lead to hard errors, and may occur at unexpected places (like when you want to show a error message)
A good (or scary) overview is on this blog entry:
http://www.rvdh.de/2010/01/06/why-you-cant-run-rails-23-apps-on-ruby-19/
I also lost a lot of time trying to bring Rails 2.3.x to work with Ruby 1.9.x
(Maybe it is possible if you are always use plain ascii)
So you need first update to Rails 3.0 and then to Ruby 1.9.3 (or both at the same time)
The asset pipeline is nice when it works, but upgrading is difficult enough.
So I would just disable it until you are on Rails 4.0.
There is a lot changed with the views, like form_for helper.
It is good when you have tests that render each view at least once. You then will get deprecation warning for things that have changed.
If this is not realistic, then you should try to test all things of your app manually, and
grep the log files for the deprecation warnings.
Many deprecations in Rails 3.0 will lead to errors or wrong behaviour in Rails 3.1.
For updating the ruby and rails version to new is not take much more time but in your code you have to change all the quires and model scopes and whatever which does't work in new rails version of deprecated in new ruby and rails versions.And one more thing may be many gems which have support to ruby 1.8.7 will not support the new ruby version and same thing for the rail.
My suggestions is just, you first check the dependencies of your application with new versions and the get a decisions.I have knowledge about it because i have also upgrade a full application from ruby 1.8.7, rails 2.3.5 to ruby 1.9.3 and rails 3.2.13.
I am running an application on Rails 2.3.8. I am planning to upgrade it to Rails 4.0 (which is in RC). What will be the easiest way for me to do this? Do I need to first upgrade to Rails 3.x?
Note: in my current implementation, I am using starling and ferret; as part of upgrade I am also considering to move to sidekiq and sunspot
This is a multi-step process, and depending on the size of your application, it can take a long time. At each step, you'll want to test your application for bugs and problems and broken gems (because they are most certainly going to crop up). I have included links for the most complicated steps. Here is the path of least pain:
Update to Rails 2.3.18.
Update to Ruby 1.9.3.
Update to Rails 3.0.
Part 1
Part 2
Part 3
Update to Rails 3.1.
Update to Rails 3.2.latest.
Update to Ruby 2.0.latest.
Update to Rails 4.0.
Update from Rails 4.0 to Rails 4.1.
Update from Rails 4.1 to Rails 4.2.
Update from Rails 4.2 to Rails 5.0.
Update from Rails 5.0 to Rails 5.1.
Bonus: If you have a large application, this is going to take a long time. If you have a large team, long-running branches become a huge headache because of recurring merge conflicts. One strategy for mitigating this is to dual boot your application with both versions of Rails so that you can have the new version running on your master branch, rather than on a long-running branch of its own.
Aaron Gray's answer is very useful, but sometimes it's very difficult after upgrading to find the differences between rails version in the code. I mean, many times after upgrading something doesn't work. Maybe could be some changes in the file or some file could be added or removed in newer version. There is a nice tool, how you can find out all differences between version and compare them. It's on Rails differences and could be very helpful to discover some potential mistakes and bugs.
I recently learned Rails (Rails 3 to be specific) and got a small project maintaining a Rails 2.3.2 app.
So, as you might expect, I keep running into differences between what I learned in Rails 3 and what I'm working in.
For example 'rails server' command in Rails 3 is 'script/server' in Rails 2.x.
What else should I know to maintain my sanity?
If you're new to rails, I don't know if you'll see a lot of differences. The rails server command is one thing however.
The other big thing is the use of .gemspec in Rails 2.3.5 instead of Bundler and Gemfiles in Rails 3. Installing gems/specifying which gems your app uses is way better in Rails 3 I think.
The rest are mostly syntax changes and depreciated functions in specific areas (e.g. javascript generators).
This Blog does a good job of listing most of the major changes in more detail.
Hope that helps!
Starting a new web app with Rails 3. I'm still relatively new to web development and have really enjoyed all the internet resources available to me while working in Ruby 1.8.7 and Rails 2.3.5. Any advice against using Ruby 1.9.2 on my new project?
I have been successfully converting all my Rails projects (except one, but I'm working on it) from Ruby 1.8.7/Rails 2.3.5 to Rails 3.0.0 and Ruby 1.8.7/1.9.2 RC2 and both environments are pretty stable.
Fortunately, things changed since I posted this question.
Rails
Unless you really have something that prevents you to do that, I strongly encourage you to start with Rails 3.
The effort required to upgrade an application from Rails 2 to Rails 3 should discourage you from starting from Rails 2.
Talking about plugins and Gems, many developers are starting to convert their libraries to Rails 3. Currently there's a very high level of compatibility.
Furthermore, Rails 3 focused plugins tends to be quite more powerful to the Rails 2.3 ones, thanks to the new Rails plugin API. They can load tasks, they no longer abuse monkey patching or rely on internal hacks.
Also, Rails 3 is just around the corner. Unless your project will be deployed in 1 week, the stable version will probably available before you deploy your code.
I this would not happe, consider that I'm currently managing a couple of Rails 3 project in a production environment and they are pretty stable (Rails 3 RC1, the Beta 4 has a really weird bug in the caching environment).
Ruby 1.9.2
Ruby 1.9.2 is way more powerful than Ruby 1.8.7. If this is a brand new project, I suggest you to use the 1.9 branch.
Usually, it's more easy to start a new project in Ruby 1.9 than converting an existing one.
Ruby 1.9.2 is faster, even more faster than REE. The most part of the common Ruby 1.8.7 Gems work with Ruby 1.9 except a few ones, such as RCov.
Again, it's very hard you're going to need a library which doesn't work with Ruby 1.9.2.
If it happens, chances are this is an outdated library and a better replacement is probably available in the Ruby ecosystem.
If you can't find an alternative, remember that Rails 3 provides an excellent way to use custom libraries, thanks to Bundler.
You can fork the project and ask Bundler to use your fork. You can even integrate the library in your repos and ask Bundler to load the library from a path.
Conclusion
From my personal experience, I've been very happy with Ruby 1.9.2 and Rails 3.
This is by far my favorite environment and my default environment for new projects.
If you can't use Ruby 1.9.2 try with Ruby 1.8.7.
On the other side, I strongly encourage you to start with Rails 3.
It ultimately depends on what the project is. If it is a personal project, and you are using it as a means to learn Ruby/Rails, than I think it would be worth learning and using the latest tools. If this is client work, or a project that your main goal is just to complete the thing, 2.3.5 / 1.8.7 would probably be the best choice, because of resources as you mentioned, and a lot of supporting libraries/gems will just work. You will have to learn Rails 3 / Ruby 1.9.x at some point because that's definitely where the community is headed.
I would do some research and see what gems you will need for your project, and make sure that everything is supported if you choose the Rails 3 / 1.9.2 route. Also, join the irc and ask around about other people's experience with whatever gems are in question.
I can tell you that I have a small Rails 3 / 1.9.2 application that runs just fine in production, although it is very small and a personal project.
You might want to try out Ruby 1.9.2 by using RVM
I've been using it off and on to develop some Rails3 apps while maintaining our current production sites (all the way down to Rails 2.2 / Ruby 1.8.5).
Only gripe being having to remember to start RVM up ^^
I'm developing an application with Ruby on Rails that I want to maintain for at least a few years, so I'm concerned about the next version coming up soon.
Going from Rails 1 to Rails 2 was such a big pain that I didn't bother and froze my gems and let the application die, alone, in the dark.
On this project I don't want to do that. First because this new version looks awesome, but also because this application may turn into a real product.
How can I prepare my application so that it will be upgradable with as little changes as possible.
How time consuming do you think switching version will be?
And what about my server? Deployment?
I'm already looking at deprecation notices... what else can I do?
The best thing you could do would be to follow development of Rails 3 via blogs and the Github repository and keep up a copy of your app along with it.
The official Ruby on Rails blog is updated with "What's new in Edge" posts every once in awhile. There are other blogs that often write about new things in edge as well. Larger features are often highlighted in these blogs, so you know about all the cool new features you can play with.
I'm not sure how close Rails 3 is to release (last I heard the core team was talking about a release at RailsConf 2009 in May), but you can always freeze the edge version of Rails into your application and just see what breaks. If you are using git, or another DVCS, you might make a branch specifically for Rails 3 and periodically update Rails to the latest edge code. Just be aware that edge Rails is a moving target so things in your app may break or fix themselves as you are pulling in newer Rails code.
Update:
Jeremy McAnally has a ton of info on upgrading from Rails 2 to Rails 3 on his blog.
http://omgbloglol.com/
I don't think there is going to be a major problem. Going off what was said in that initial report the Rails team realized that they can't do a major rewrite like they did from 1 to 2.
They even say:
I’m sure there’ll be some parts of Rails 3 that are incompatible, but we’ll try to keep them to a minimum and make it really easy to convert a Rails 2.x application to Rails 3.
I would be more concerned going from Merb to Rails 3.
The single most important thing you can do to make it easy to migrate to a new version of rails is to have a comprehensive test suite. Without a good test suite, I would never have the confidence that the new version of rails hasn't broken something in my app. On the current Rails app I'm working on, we started on Rails 2.1.1 back in October of 2008. Since then, we've migrated to Rails 2.1.2, 2.2.2, 2.3.2, 2.3.3 and now 2.3.4. I did the migrations to 2.3.2, 2.3.3 and 2.3.4...and for the 2.3.2 and 2.3.3 upgrades, we had some failing tests that alerted us to problems we would not have discovered without having such a good test suite. The failing tests actually alerted us to a regressive bug in rails that there was a patch for on the Rails lighthouse but that was not included in the release (since it was discovered, right after the release).
Once you've got that test suite in place, just stay current with each rails release (waiting a couple weeks to upgrade is fine, just don't skip any of the releases).
Yehuda Katz (a member of the Rails core team) has stated that there will most likely be a transitional release, containing deprecation warnings and such.
So as long as you have a good test suite to expose the inevitable upgrade problems, and stay current with the Rails release, the migration to Rails 3 should not be too difficult.
As simple as:
One
Two
Three
Great screencasts from Ryan Bates.
For preparing your application, the best way it what Jared said. Follow the Rails3 development.
For the time consuming, I think it depends of how you've followed the rails3 development before it's release.
And for the deployment, it shouldn't take too much problems. Rails 3 will be using Rack. So you can start it with mongrel, passenger or any server/gateway it shouldn't give you any problem.
There are some major changes in Rails 3, I posted about my experience upgrading my app to Rails 3 here: http://rails3.community-tracker.com/permalinks/5/notes-from-the-field-upgrading-to-rails-3
A good start in preparing would be to migrate over to using bundler. And doing a very deep review of strings that will go through the new XSS protection scheme.
There are going to be some automated compatibility checkers. Also, keep an eye on http://www.railsplugins.org/ so that you know if the libraries you depend on are going to be upgraded. The Rails Core team seems to be giving a lot of advance notice to the community this time around, so any lib that is actively maintained should be good to go.
Just do one thing
take a backup of your old version project first and then
on terminal(command prompt) write
rails new path/of/the/project
for example if my 2.3.* project is at home/rails_projects/myproject then
rails new home/rails_projects/myproject
or
cd home/rails_projects
rails new myproject
It will ask if there is any modifications done in any /config or other files. Do appropriate.