I want to update a huge Ruby on Rails v2.3.18 application to Rails v4.2.4 (latest).
After doing some research, I've came up with:
After Rails 2.3.18 (March 18, 2013), a total of 195 versions have been released until Rails 4.2.4 (August 24, 2015)
in which 92 are stable releases
and 2 major releases
775 files changed
909 commits
Our application runs Ruby on Rails 2.3.18 on Ruby 2.1.5.
Ruby should also be updated from this version to 2.2.x ?
Are there any individuals who achieved or tried this "leap of faith" and succeeded ?
Where should I start from in order to achieve my goal?
What is the basic flow of updating any Ruby on Rails application?
I have also been pondering this issue with some 5 year old projects - do I keep using rails 2.3.18 LTS https://railslts.com/ , or migrate to rails 4.2, knowing that I will then need to look at annually/biannually updating the rails version. I suspect I will be more succesful in doing a selective replacement as new functionality is developed.
Anyway, the information I found seems to indicate it is a long step by step process:
This post may be of help - https://groups.google.com/d/msg/rubyonrails-talk/y0q1fc8N_GU/H2xOsy2mYpwJ
In it Rob Biedenharn suggests
• 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.
• 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.
Related
I would like to use immutable.js, and see that v4.0.0 is at rc.12. That version string seems to indicate that v4.0.0 is not yet released. Is that because there is a problem with v4.0.0, and we should use 3.8.2, which is three years old? Is there a good fork that publishes v4.0.0 (or higher), so I can depend on it without raising questions about depending upon pre-release packages?
Last autumn a new group of devs have started work to finish 4.0 at the immutable-js-oss repo. It's not clear yet whether (or when) we can merge it back into the main repo (otherwise it will be released as a new package).
There are only a few things left to do for a final 4.0 release, 99% of the issues are already finished. If you are curious, have a look at the issues of the 4.0 milestone. The changes are mostly for compatibility with version 3.x and a few cases for handling very special data (e.g when passing nodejs objects to isolated sub-processes).
Our electron app uses RC12 since 2019, before it was on RC9 for a year. So far none of the 10'000 pilots using it crashed a plane, so I would say it works quite well.
We have a reasonably big project in Django, that had started to push at the limitations of Django (we mostly use Django for database-related stuff, not web interface), and we decided to switch to SQLAlchemy, while it's still possible (we don't want to get ourselves in this position:).
The problem is, it really seems this is the worst time we could have picked. SQLA is on the verge of releasing version 1.0, which will probably be a big change in the interface. More importantly, it seems like there is some trouble with releasing it: more than a month ago, Mike Bayer tweeted that release candidate will be available via pip --pre, but it still hasn't happened.
Docs are updated to 1.0, and the bitbucket repo shows no diff between master and 1_0 branch. If this were Django, I'd just clone a repository and install it directly - there is an official blessing for such method in Django documentation. But I can't see any hint that this is "accepted behaviour" in SQLA community. For example, installation page doesn't mention 1.0 at all.
Am I too paranoic? Should we just use 0.9.8, and then make a few changes when 1.0 comes out? Or should we build 1.0 manually? Or it would be better to wait? (How much? I realize SQLA team doesn't want to heap up pressure to themselves by talking about an release date, but Mike has kinda already done that with that tweet.:)
I realize this is not exactly an objective question, but someone having a knowledge of SQLA process might have valuable advice. For example, if someone asked me same thing about Django 2.0, I'd tell them "if it isn't a mission critical app, just clone and build from the newest repo state - the chance of breaking is small, and you're getting much better interface". And I'd have official docs behind me.
As of the day of rewriting this answer, to answer how to choose from SQLAlchemy 0.9.8 (stable version released on October 13, 2014) or 1.0 ("upcoming" version), personally I will pick the stable version.
As a software life cycle, beta / bleeding edge / nightly build versions tend to have more bugs or breaking changes, which will directly lead to breaking up your system / script.
Therefore, choosing a stable version is more appropriate in most cases, unless you want to have the new feature in the beta version.
Last, there are usually migration guides to upgrade your version, but not downgrade your version. In some cases (but probably not in SQLAlchemy case), upgrade is sometimes irreversible.
mysql2 gem have "Not supported on Windows" note.
I need a simple solution to do async calls to mysql database on windows. No need for ORM support.
Preferably not with Eventmachine as I'd rather not have my whole app packed inside EM.run block.
There is this, but doesn't seem to have been any changes in the past 2 years.
Perhaps it will give you what you need and I'm sure you can contact the author.
https://github.com/chrismoos/async-mysql
I'm using JRuby 1.5.6 on Rails to build myself an application that will periodically go away and retrieve any RSS podcasts that I have subscribed too.
I've chosen JRuby primarily because I'm familiar with Java, wish to utilise the Rails framework and most importantly I'm able to perform the "heavy lifting" tasks in Java when Ruby falls short of my requirements. Up to now (and I'm still in the early stages of development) this hybrid approach has been working extremely well.
I'm now at a point where I'm needed to implement scheduling of periodic and long running tasks to a background process. My requirements are to have a database backed scheduling system that is, ideally, well documented, currently maintained and clean.
My problem now is that after many days of researching suitable off the self gem packaged solutions, I appear to be left with very few options because of my use of JRuby.
Some of the gems I've tried...
rufus scheduler
Having used this before I'm happy with it's interface and documentation, however there is a lack of database persistence, hence a deal breaker for my requirements.
delayed_job
My ideal solution would be delayed_job. Good documentation, still being maintained and database backed, however, breaks under JRuby due to ObjectSpace being turn off (we can however fix this by re-enabling) but more fatally the dependence on the daemons gem which throws a "fork is unsafe and disabled by default on JRuby" error due to limitations within the JRuby implementation.
There is a fork on github that doesn't have a dependence on daemons, however I'm not happy switching to a fork off the main development branch and I'm still left with the ObjectSpace issue which I'm unsure as to it's performance impact.
quartz-jruby
While there have been various quartz based gems before, this very recent offering is another attempt at providing a slick ruby-like interface. There is however minimal documentation and I'm unsure as to if this can be database backed, my gut feeling is that it is not.
The problem
While I've only highlighted 3 options here, I'm aware that there are others available. I've however not been able to find a solution to tick all 3 requirement boxes (docs, maintained, database backed).
So the questions are...
Has anyone else been in this situation and come up with a solution?
Has anyone managed to get delayed_job working in whatever form?
Are there any better solutions out there that I've overlooked and will satisfy my needs?
We have been using delayed_job (collectiveidea/v1.8.4) under JRuby in production for over an year now.
We have not enabled ObjectSpace and also we do not use daemons gem.
Created a simple rake task
namespace :product do
desc "Start Delayed Job Worker"
task :dw => :environment do
Delayed::Worker.new.start
end
end
and daemonize it in the OS dependent way. On linux,
nohup jruby -S rake product:dw > $log_dir/delayed_job_console.log 2>&1 &
I would recommend resque as the queueing system. Resque is similar to DelayedJob, but in my opinion much better. It was developed at GitHub and is used as their queueing system. I've also been using it in production for almost a year and I've been very happy with it.
Resque definitely has JRuby support, and all you have to do to get scheduled jobs is have a simple scheduler. Some recommend resque-scheduler, though I like to keep it simple and use clockwork which has a nice DSL for writing simple cron-like tasks to queue up schedulers (see: clockwork README). With that, you can just schedule things like so:
every(1.hour, 'tasks.alert') { Resque.push(:cron, :class => 'TaskAlert', :args => []) }
Check https://github.com/kares/jruby-rack-worker
This allows delayed_job solution under jruby environment.
Still work in progress.
At the time of writing, my experience is that it works fine with a single worker.
Though I have difficulties at making additional workers run.
I originally asked this question in Dec '10 and have since developed a solution that I thought would be worth posting back for others to reference.
As others have pointed out, it is possible to get libraries like delayed_job working with JRuby and for some this might be an acceptable solution. I however didn't want a solution that required an additional process running and with that in mind I have developed a gem that utilises Java's Executor framework and integrates it with ActiveRecord.
The result is acts_as_executor which allows a Rails 3.x application to interact with executors and tasks (which will run in a proper Java thread) just as it would any other ActiveRecord model.
I've recently moved the gem to release candidate 1. Take a look at GitHub and Rubygems.
N.B. RubyGems default page still shows beta2 for some reason. rc1 is still the latest release however.
I need to define a runtime environment for my development. The first idea is of course not to reinvent the wheel. I downloaded macports, used easy_install, tried fink. I always had problems. Right now, for example, I am not able to compile scipy because the MacPorts installer wants to download and install gcc43, but this does not compile on Snow Leopard. A bug is open for this issue, but I am basically tied to them for my runtime to be usable.
A technique I learned some time ago, was to write a makefile to download and build the runtime/libs with clearly specified versions of libraries and utilities. This predates the MacPorts/fink/apt approach, but you have much more control on it, although you have to do everything by hand. Of course, this can become a nightmare on its own if the runtime grows, but if you find a problem, you can use patch and fix the issue on the downloaded package, then build it.
I have multiple questions:
What is your technique to prepare a well-defined runtime/library collection for your development?
Does MacPorts/fink/whatever allows me the same flexibility of rehacking if something goes wrong ?
Considering my makefile solution, when my software is finally out for download, what are your suggestions about solving the potential troubles between my development environment and the actual platform on my user's machines ?
Edit: What I don't understand in particular is that other projects don't give me hints. For example, I just downloaded scipy, a complex library with lots of dependencies. Developers must have all the deps setup before working on it. Despite this, there's nothing in the svn that creates this environment.
Edit: Added a bounty to the question. I think this is an important issue and it deserves to get more answers. I will consider best those answers with real world examples with particular attention towards any arisen issues and their solution.
Additional questions to inspire for the Bounty:
Do you perform testing on your environment (to check proper installation, e.g. on an integration machine) ?
How do you include your environment at shipping time ? If it's C, do you statically link it, or ship the dynamic library, tinkering the LD_LIBRARY_PATH before running the executable? What about the same issue for python, perl, and other ?
Do you stick to the runtime, or update it as time passes? Do you download "trunk" packages of your dependency libraries or a fixed version?
How do you deal with situations like: library foo needs python 2.5, but you need to develop in python 2.4 because library bar does not work with python 2.5 ?
We use a CMake script that generates Makefiles that download (mainly through SVN)/configure/build all our dependencies. Why CMake? Multiplatform. This works quite well, and we support invocation of scons/autopain/cmake. As we build on several platforms (Windows, MacOSX, a bunch of Linux variants) we also support different compile flags etc based on the operating system. Typically a library has a default configuration, and if we encounter a system that needs special configuration the configuration is replaced with a specialized configuration. This works quite well. We did not really find any ready solution that would fit our purpose.
That being said, it is a PITA to get it up and running - there's a lot of knobs to turn when you need to support several operating systems. I don't think it will become a maintainance-nightmare as the dependencies are quite fixed (libraries are upgraded regularly, but we rarely introduce new one).
virtualenv is good, but it can't do magic - e.g. if you want use a library that just MUST have Python 2.4 and another one that absolutely NEEDS 2.5 instead, you're out of luck. Nor can virtualenv (or any other tool) help when there's a brand new release of an OS and half the tools &c just don't support it yet, as you mentioned for Snow Leopard: some problems are just impossible to solve (two libraries with absolutely conflicting needs within the same build), others just require patience (until all tools you need are ported to the new OS's release, you just need to stick with the previous OS release).