Rob, this is a useful summary, Thanks. I face the same problem, having two large apps that are in constant development and so without putting a stop to development and focusing on upgrading (something that would be very hard to sell to one of my clients), I am strugling to see a way forward. I have got to 2.3.18, and have been looking at when to upgrade Ruby, and keeping the right version of gems and rubygems seems to also be a challenge along the way.
For me at the moment, the greatest hurdle seems to be when I need to go to the asset pipeline in 3.1. Your summary identifies that - thanks. I am also using Prototype js, and am wondering whether I should migrate to JQuery along the way, or get as far as possible with Prototype. There is not masses of js, but enough to make me wonder. I have done some work on 3.1 with JQuery, but it could take some effort to implement that in my current codebase, and I get the sense that things will look quite different with the js at Rails 4 anyway. In giving this ongoing thought, I have been wondering if it would be possible to upgrade my apps in sections, by breaking them into separate functional areas, and making them separate apps (perhaps on separate servers). My thinking being that this might make it possible to upgrade each section in turn (re-writing straight into Rails 4) and so break the workload down. I have one section that handles mostly scheduled maintenance and this is a clear candidate. I would have to mirror the models, which might become very cumbersome though. I haven't got very far with this thinking, and would be interested if anyone has any thoughts. Another main issue that I can see is the need to provide consistent login when a user moves between the apps, but I think this should be achievable. I have also seen some stuff written about using engines to help to break an app down into more manageable and separate parts and have thought that this might also be worth looking into at the same time. Doing the upgrade in parts would also make it easier to ensure the parts being upgraded do have up to date tests. I would be interested on any wisdom from others who have already trodden this path. Thanks tonypm On Thursday, 3 July 2014 20:54:59 UTC+1, Rob Biedenharn wrote: > > > On 2014-Jul-3, at 15:49 , Rob Biedenharn <r...@agileconsultingllc.com > <javascript:>> wrote: > > > On 2014-Jul-3, at 11:25 , Jason Fleetwood-Boldt <te...@datatravels.com > <javascript:>> wrote: > > As was suggested to you by other posters, please read the upgrade guide > carefully (here is the official one > http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.html) > > it is recommended that you have very good test coverage before you begin. > > I suggest you use a tool like simple-cov to make sure all your lines of > code are tested before you begin, as well I'd recommend integration > coverage for every major end-user "happy path" through your app. > > When you are sure you have complete test coverage, change the version in > the Gemfile and then run "bundle update rails" > > > On Jul 3, 2014, at 10:28 AM, M,Gopi M.gopinath <gopi1...@gmail.com > <javascript:>> wrote: > > Hi, > Seems I need to say this first, The website which I > have Know is 8 Years old website, Developed in Ruby 1.8.6 and Rails 2.3.6, > and its as 220 tables in it and lot of controllers and views. Is there a > way to update this to current version of rails and ruby. > > > The short answer is yes, but it is certainly not easy, nor can you make a > single leap. > > Simple-cov will not help you yet as it requires ruby 1.9.3 or better. > (It's been so long that I can't even remember if there was a similar tool > that worked with ruby 1.8.6.) > > You may find it simpler to write a new app from scratch, importing (by the > time-honored cut-and-paste method) the important bits of business logic. > > However, if you want to proceed with an upgrade, this is roughly what > you'd need to do: > > • update to rails-2.3.18 > There's really no reason not to and PLENTY of good reasons that you should > have done this already. > 2.3.9 (2010-09-04) was the version that first gave deprecation warnings > for the upgrade to rails-3.0 > 2.3.18 (2013-03-18) was the last releast in the 2.3 line and contains > fixes for at least 10 vulnerabilities (some of them quite serious!) > > • get all your tests to pass (if you don't *have* tests, you'd better have > faith) > • address all the deprecation warnings > > • don't upgrade ruby yet > > https://developer.uservoice.com/blog/2012/03/04/how-to-upgrade-a-rails-2-3-app-to-ruby-1-9-3/ > But you might have to upgrade to ruby-1.8.7 as rails-3.0 doesn't > officially support 1.8.6) > > > Oh, and I took a look at > http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.html as > suggested by Jason Fleetwood-Boldt and that has a MUCH more detailed walk > though the upgrade process from 3.0 to 4.1. But if you don't have time to > go and look at that yourself, then perhaps I've given you enough with which > to weigh the upgrade v. rewrite paths. > > -Rob > > • upgrade to rails-3.0.0 (perhaps even directly to rails-3.0.20) > • get all your tests to pass > > • upgrade to ruby-1.9.2 (or perhaps even ruby-1.9.3) > • get all your tests to pass > > • upgrade to rails-3.1.12 (last of the rails-3.1 line) > This might not strictly be required, but 3.1 introduced the Asset Pipeline > and also made jQuery the default JavaScript framework. > If you have much use of Prototype or Scriptaculous in your application, it > would probably be a good idea to convert that to jQuery (and get > https://github.com/rails/jquery-ujs) > • get all your tests to pass > > • upgrade to rails-3.2.19 > • get all your tests to pass > > • upgrade to ruby-2.1.2 (there's probably no reason to just use 2.0 at > this point) > • get all your tests to pass > > • upgrade to rails-4.0.8 > • get all your tests to pass > > • upgrade to rails-4.1.4 > • cope with the new secrets.yml file > • get all your tests to pass > > • take a vacation > > Seriously, there's a lot to do if you really want to go the upgrade route. > I haven't even mentioned any of the issues that you're almost certain to > encounter with gems that cease to function with newer versions of Rails or > even newer Rubies. I'd recommend that you very seriously consider > "refreshing" the application as a simpler way to bring the application onto > a current, supported RoR stack. > > -Rob > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Talk" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rubyonrails-ta...@googlegroups.com <javascript:>. > To post to this group, send email to rubyonra...@googlegroups.com > <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/rubyonrails-talk/F60098D9-F540-4976-A917-DBD8E47D7F3E%40agileconsultingllc.com > > <https://groups.google.com/d/msgid/rubyonrails-talk/F60098D9-F540-4976-A917-DBD8E47D7F3E%40agileconsultingllc.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-talk@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/8063b167-1113-46a5-8571-2cdf3b0b0765%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
