I need to upgrade an app from v1.2.4 to v2.2.3 (as we are bumping Ruby from v2.7.2 to v3.1.2)
We have simple code which uses IMS::LTI::ToolConsumer.new, IMS::LTI::ToolConsumer.launch_url, and IMS::LTI::ToolConsumer.generate_launch_data. I cannot find any hints on how to change this code to use the new available classes (since IMS::LTI::ToolConsumer has now been removed).
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'
Some background:
I am new to Ruby and Rails and I've been assigned to get an already completed Ruby on Rails project to compile from source.
The project has, as far as I've been able to discover, little to no documentation on how to set it up. The developers are unavailable for me to contact.
After doing some tutorials and learning the basics I have been trying to get the code to compile and run. My platform/setup is currently:
Windows 7
Ruby 1.9.3
Rails 3.2.13
Although I am attempting to develop with a VirtualBox Ubuntu setup alongside of this because I suspect it will be easier in the long run.
Despite there being no Gemfile for this project I have managed to (I believe) pin down and install all of the necessary gem packages (hopefully compatible versions). I am now running into this issue:
in alias_method': undefined methodpath' for class `ActionController::UploadedStringIO' (NameError)
As far as my searches have led me to believe this is a bug that can occur when the versions of Ruby and Rails are not correct/incompatible?
Is there a way to "reverse engineer" what version of Ruby and Rails was used to develop this project in the first place from the code alone? Could this bug be caused by me using 3.2.13 Rails if the original developers were using 1.8.7 Ruby? It seems to me that if I can emulate their setup closely enough then the source should compile and I can get down to business.
Additionally I am using the default WEBrick server. Is there a way to determine what the original team used for the web service? Does it even matter if they used a Apache setup or are these server implementations mostly interchangeable aside from efficiency?
Thank you for your time. If you have any further advice on how to handle this sort of project I'd love to hear that too.
If there is no Gemfile, it points to the Rails app being 2.3 or earlier. As for the Web server, they are interchangeable, but there is really very little chance that they were using Webrick, due to its ability (or lack thereof) to handle many concurrent requests. Chances are, they were using mongrel, or passenger via Apache or Nginx.
Since I am developing a "secure" OAuth protocol for my RoR3 apps, I need to send protected information over the internet, so I need to use HTTPS connections (SSL/TSL). I read How to Cure Net::HTTP’s Risky Default HTTPS Behavior aticle that mentions the 'always_verify_ssl_certificates' gem, but, since I want to be more "pure" (it means: I do not want to install other gems, but I try to do everything with Ruby on Rails) as possible, I want to do that work without installing new gems.
I read about 'open_uri' (it is also mentioned in the linked article: "open_uri is a common exception - it gets things right!") that is from the Ruby OOPL and I think it can do the same work.
So, for my needs, is 'open_uri' the best choice (although it is more complicated of 'always_verify_ssl_certificates' gem)? If so, can someone help me using that (with an example, if possible) because I have not found good guides about?
You should find the best tool for the job and use it. You should not try to limit your usage of libraries to just Rails and the Ruby standard library, because these two alone will not always provide you with everything you need. As you have indicated, you found the right tool for the job - don't reject it just because it's not part of "official" Ruby or Rails.
You can easily manage which gems your application needs with Bundler, such that everyone on the team is, with a single command, always able to install and run the application, including automatically installing all gem dependencies. Rails 3, by default, integrates with Bundler and expects that you will use Bundler to manage all your gem dependencies.
I have a set of functionality that I am considering packaging so as to use them in multiple projects, but I can't decide whether to choose a gem or a plugin. What is the difference? Which one should I choose?
Gem is currently acknowledged as the 'best practice' for Rails. (You can also package as a gem and include an install.rb so that your project can be optionally be installed as a plugin - see this Rails dispatch article).
Basically the only reason to go with a plugin is if your users will want to be able to modify the code more often than not, as it stores a copy in vendor/plugins. However, with the advent of bundler it's pretty simple to store your gems per repository as well and modify them.
If you go with gems, you get the advantages of dependencies, versions, and the functionality that rubygems.org offers for searching, alerts and so on.
Definitely make it a gem!