What the current stable recommended release of Ruby? 1.8.7 or 1.9.x?
It depends on what exactly you are talking about: deployment to production? Development? Testing?
Personally, for production, I would recommend the not-yet-but-real-soon-now-released Ruby 1.9.2 if you can get away with it, otherwise stick with Ruby 1.8.7 plus Marc-André Lafortune's backports library for the time being.
For development, use Ruby 1.9.2.
For testing, use Ruby 1.9.2 if you deploy to Ruby 1.9.2, otherwise if you deploy to Ruby 1.8.7, use both Ruby 1.9.2 and Ruby 1.8.7 (to ensure that you don't accidentally introduce any "1.8isms" that would prevent you from updating later. This includes dependencies on third-party libraries that don't yet work on Ruby 1.9.)
I don't think it makes much sense to use Ruby 1.9.1 right now. Ruby 1.9.2 is going to be released very soon and it has some small but important improvements and changes plus some really nifty enhancements over 1.9.1.
I will be deploying a rails(v 2.3.8) app & was wondering what version of ruby should I be using. My deployment environment is Ubuntu/Apache/passenger (mod_rails)
AFAIK, the recommended version for Rails 2 right now is Ruby 1.8.7, however for Rails 3 it is likely going to be Ruby 1.9.2.
[...] what are kind the ruby + rails + gems compatibility issues, that one should watch out for.
Upgrading from Ruby 1.8 to Ruby 1.9 is pretty easy but it is somewhat time-consuming. (In my case, I had to change almost all of my files in some way or another, but all of the changes were completely trivial.) Unfortunately, this means that there are still third-party libraries out there that don't work on Ruby 1.9. And if you depend on one of those, then you are screwed. You can get an overview of what works and what doesn't on the Is It Ruby 1.9? website.
Note, however, that there is usually a much bigger problem than what version of Ruby you are using and that is what implementation of Ruby you are using. Pretty much all implementations of Ruby have their own private extension API and extensions that are for example written for MRI, don't necessarily work on YARV, REE or Rubinius and they certainly don't work on JRuby or IronRuby. For some strange reason, Ruby programmers seem to hate Ruby and much prefer writing C instead, which unfortunately means that their code is intimately tied to one particular implementation of Ruby and doesn't work in others.
I would love to use 1.9.x, since I have heard it provides significant performance improvements.
That is a very common misconception that unfortunately doesn't want to die. Ruby 1.9 is in no way, shape or form faster (or slower) than Ruby 1.8, for the simple reason that Ruby 1.9 is a programming language and a programming language is just a bunch of abstract mathematical rules. A programming language isn't fast or slow. It just is. You cannot execute a bunch of abstract mathematical rules.
The only thing that is relevant when it comes to performance is which execution engine you are using, the version of the language is completely irrelevant.
Right now, there are five Ruby execution engines that are generally considered to be of production-ready quality: IronRuby 1.1, JRuby 1.5.1, Rubinius 1.0.1, YARV 1.9.1-p429 (and also I personally consider YARV 1.9.2-RC2 to be production-ready) and MRI 1.8.7-p299.
IronRuby 1.1 is an implementation of Ruby 1.8.6 for the ISO CLI (or more specifically for the DLR, which is a Dynamic Language Runtime for the ISO CLI).
JRuby 1.5.1 is an implementation of both Ruby 1.9.2-trunk (as of revision 24787) and Ruby 1.8.7-p249 for the JVM.
Rubinius 1.0.1 is an implementation of Ruby 1.8.7 (I don't know which patchlevel) for Unix-ish systems.
YARV 1.9.1-p429 is an implementation of Ruby 1.9.1-p429 for Unix-ish systems as well as Windows (plus a couple of others).
MRI 1.8.7-p299 is an implementation of Ruby 1.8.7-p299 for Unix-ish systems as well as Windows (plus a couple of others).
Then, there is Ruby Enterprise Edition 1.8.7-2010.02. REE is a minor variant of MRI, produced by Phusion, the same company that also produces Passenger. In particular, REE 1.8.7-2010.02 is based on MRI 1.8.7-p249 (and thus implements Ruby 1.8.7-p249), but it adds some backports for compatibility problems that were fixed in Ruby 1.8.7-p299. The main difference between REE and MRI, however, is that while MRI is specifically tuned for short-running scripts which don't allocate much memory, REE is specifically tuned for long-running server processes which allocate significant amounts of memory.
In terms of performance, in my personal experience, JRuby is the fastest, and it doesn't actually matter whether you run it in 1.8 mode or 1.9 mode. Although you have to be careful: JRuby itself doesn't actually do any interesting work, it mostly depends on the JVM for performance. Therefore, you need to run JRuby on a modern high-performance JVM such as the server version of Oracle HotSpot 1.6.0u21 with the C2 compiler or Oracle JRockit R28.0.1 for it to really shine. The difference becomes really dramatic when running multithreaded code on a multicore machine (such as for example Azul Systems' 864-core Java appliance), because MRI, YARV, REE and Rubinius cannot actually run multiple threads in parallel and thus are only ever going to use at most one core, whereas JRuby and IronRuby will happily use all available cores.
In most benchmarks, YARV is equal to or slightly ahead of JRuby, but I have found that those benchmarks tend not to be very representative of the code I write, so for my code, JRuby is almost always significantly faster than YARV. Unless your company happens to be in the business of selling Fibonacci Numbers, the Ruby Benchmark Suite is probably not going to tell you much, especially since those benchmarks tend to only run for seconds, whereas Rails apps tend to run for months.
However, note that Phusion Passenger only supports MRI, REE and YARV.