Part of our team is working to upgrade our large codebase from Rails 3.2 to 4.2.
Before that is finished, I'd already like to use ActiveSupport::MessageVerifier for a new feature. The release notes for 4.1 included them so I naturally assumed they were introduced in 4.1.
I was trying to estimate the effort of backporting ActiveSupport::MessageVerifier to Rails 3. Going through its history, I discovered that the original commit has been included in Rails core since 2.3.0.
Now I wonder:
Is it safe to use the message verifier shipped in 3.2 in production?
What's new in 4.1 is easy access to named verifiers that use secret_key_base. ActiveSupport::MessageVerifier has been used for signed cookies since 2.3.6 (here's the commit that added it) so I would definitely consider it production ready.
Related
Currently my application run on rails 3.1.3 & ruby 1.9.3.
I want to upgrade my application into rails 4.1 & ruby 2.1
Can anyone tell me how to upgrade the rails application ?
Thanks in advance
There is no specific defined way to upgrade. You can take reference from http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.html or many other blog posts that people have written based on their personal experience. Just google them.
http://www.sitepoint.com/get-your-app-ready-for-rails-4/
https://developer.uservoice.com/blog/2012/03/04/how-to-upgrade-a-rails-2-3-app-to-ruby-1-9-3/
However follow a few points to make it easier. Upgrade one at a time. Better upgrade your ruby first, then rails in second cycle.
Do through testing at each step as the gems are likely to fail due to their dependencies.
Upgrade you gems manually and avoid bundle update
As addition to #shivam 's answer.
Guides often do not contain all the info. And they often do not say why some steps a necessary.
The most professional way is to read the release notes at least for the next major version.
Rails follows semantic versioning, meaning that all following 4.x.x versions are not allowed to introduce breaking public api changes.
Check the Rails 4 Release Notes. Watch out for things marked as deprecated and stuff that was extracted to a separate gem. The best tutorial available is the Upgrading to Rails 4 Screencast.
The most tricky part about the upgrade is the change from protected_attributes in models to strong_parameters in the controllers as a default mechanism against mass assignment protection.
If your app already heavily relies on protected_attributes it can be a tremendious task to move this protection outside of the model to every controller. In that case it is recommended to stick with protected_attributes by just including them as extra gem(same name).
In case of the ruby update. You can almost safely update to 2.1.2 from 1.9.3. Ruby follows semver only since Major version 2. If there even have been some incompatibilities since 1.9.3 the probability is very little, that your app used this features. We could upgrade all of our apps from 1.9.x to the last 2.x.x without a single ruby code change
I have a Rails app that was built on 3.2.6. I want to upgrade it to the latest version of 3.2 (which seems to be 3.2.18). Can anyone tell me what changes will need to be made besides just changing the Rails version number in the Gemfile? Is there a more stable version I should be upgrading to instead of 3.2.18? I am extremely new to Rails development and I am not finding much help elsewhere on the web.
EDIT: I tried updating to 3.2.18 briefly just to see if the behavior of my application changed, and once I had done so, the main page would not even load, claiming the template was missing. This seems to indicate that I need to manually go in and fix something.
Rails uses semantic versioning. This means that 3.2.x will work if the application was working in any version of 3.2.x.
The latest stable version of Rails is 4.1. I would recommend building new applications with the latest version, unless you know for certain a required feature was deprecated.
EDIT: This response on rails core describes the versioning https://github.com/rails/rails/issues/9979
X.Y.Z
Z - only bug fixes, no API changes.
Y - new features, may contains API changes.
X - new features, will contains API changes. Just bumped in special occasions
change the rails version in Gemfile and run 'bundle update rails'
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.
In order to migrate smoothly a Rails 3.0.10 application which need to grow up with many new models and controllers over rails 3.1.1, I wonder if we could just mount the old app under the new 3.1.1 leaving one team implementing the new features, while the other carefully migrate the old 3.0.10 components.
Is that possible ? Is it desirable ? If yes how can we do it ?
Any idea or experiences is welcome.
UPDATE
... we also are in a phase which every programmer is starting a new feature, with no resources for porting currently. So I said, way don't start with many brand new self contained/tested apps (rack + sinara + old rails 3.0) driven by (mounted on) rails 3.1.1 working as a router/container ?
I've in mind something like Paul Dix describe in his "Service-Oriented Design with Ruby and Rails" book.
New features, can also be started over Rails 3.1.1, on top of that old 3.0 app, until the first programmer will be ready to start migration ... what do you say ?
Luca
I'd recommend not doing it this way. What you end up doing is doubling your work - you now have to test every feature in multiple codebases, for little benefit.
Just upgrade the app from 3 -> 3.1 and move on with your day. It shouldn't be hard, 3.1 is a point release and should be mostly backwards compatible.
Historically the main issue with upgrading has been 3rd party library dependencies besides Rails - they often break when rails is updated, and then you have to either fix them, rewrite them yourself, switch to another one that works on the new rails version, or just wait to upgrade until they are compatible, all which may be undesirable.
Fortunately, I don't think a lot of gems broke in between rails 3 and 3.1 so you shouldn't have that issue.
Edit: if you're concerned about the changes to css/javascript/html in 3.1, I can only imagine you're assuming the asset pipeline changes things. in my experience, it doesn't. The asset pipeline, to my knowledge, is mostly optional. I think you can still reference css/javascript in the same manner as rails 3.0 if you want
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.