I've actually found the documentation for projects in the Ruby community, on the whole, to be quite excellent. That being said, I can sympathize with the confusion getting things deployed, if only because there are so many options. The best bet for a beginning, IMHO, is to give Heroku a try when getting your first app deployed - they have some really excellent documentation.
As a beginner, trying to deploying a rails app to production from scratch is likely to drive you a bit crazy.
I had difficulties getting heroku installed, even though I'm using ubuntu 10.04 LTS (as they are). It took many hours over several days, and several attempts.
One problem is that their deb package doesn't specify ruby as a dependency. Another problem is that you have to examine their inlined bash install script to get to the .deb package to diagnose that. Another problem was that ubuntu's standard package repositories didn't include the version of ruby they needed (ruby1.9.1 - though I just checked now, and it seems to be available again). So I installed rvm, suggested by www.ruby-lang.org as an easy route, which needed me to install a whole bunch of other stuff, and finally installed the latest version of ruby - but this was too recent for their package to accept. sigh
Eventually I found an old, undocumented gem of theirs that would install their command-line tool (well, half of it anyway). Maybe it's seamless if you already have ruby installed - but it's a terrible way to start ruby, in my experience anyway. Possibly it's more streamlined on Windows/Mac.
Then... all three versions of ruby that I tried (1.8, 1.9.1, 1.9.3) had changes that broke my tiny toy code. So astonishing, I'm not even mad.
Look at Python, with 5-year support for Python 2 before breaking compatibility with Python 3. And Java, well, I've never heard of code being broken (assert could have, but never heard it happen).
Ruby is labour-intensive - that's the price of constant (incompatible) improvement. Part of that price is documentation that goes out of date, instructions that go out of date, code that goes out of date. It becomes unrealistic to invest in Ruby - unless you plan to be working intensively on it anyway. Which I think does make sense for its original professional users, who are constantly iterating anyway. But it's not good for people who missed the early wave, when ruby was friendly.
It's a shame, because there's a lot of cool ideas in ruby and cool projects using it. I guess that's the trade-off. But, well, it took so much effort to get heroku installed that I haven't used ruby since.
> Then... all three versions of ruby that I tried (1.8, 1.9.1, 1.9.3) had changes that broke my tiny toy code. So astonishing, I'm not even mad.
I think you confuse your releases. Neither 1.8.7 nor 1.9.3 did break anything major. The only two releases with major breakage that should have affected you in recent years are 1.9.1 and 1.9.2.
The changes in ruby that break compatibility are listed in the release notes of every release.
> Look at Python, with 5-year support for Python 2 before breaking compatibility with Python 3. And Java, well, I've never heard of code being broken (assert could have, but never heard it happen).
Not sure what you mean about Python. Python has roughly the same policy as Ruby about API breaking changes.
The changes between Python 2.X and 3.X are also way larger than between Ruby 1.8.X and 1.9.X. Porting our code from 1.8 to 1.9 was not much work.
Does it make sense to you that if there is a breaking change between 1.9.1 and 1.9.2, then there is a breaking change between 1.9.1 and 1.9.3?
I'm just stating my (local) experience; I don't have a global god's-eye view of ruby.
I'm not an expert in ruby; I'm just trying to get started. You seem to expect a beginner to know exactly which versions introduce a breaking change, and to read the release notes in detail - and understand them, which is difficult for someone who has not yet learnt ruby or its terminology.
When you start to have categories of breakage, as "major" or not, and defend porting code between versions as "not much work", it means you accept some breakage as normal. To me, a breaking change is one that causes code to stop working, and require extra labour. Python and Java don't do this (nor Windows, x86 or ARM).
Note that from 1.9.1 to 1.9.2 is not a major release. It's not even a point release. It's a point-point release with "major" breaking changes (according to you).
As I carefully said, this is a consequence of constant improvement (contrast with Java, c#, x86). (guessing: do you think it's partly due to the power of ruby making security harder?). The trade-off doesn't suit beginners. Note that back-compatibility is a "successful programming language problem" - no one complains if a toy language breaks. I'm just drawing attention to the downsides, because if uncorrected, in the long-term, it may lose the next generation of coders.
Look, I'm not out to attack Ruby; I like ruby. But this is a real problem. Disregarding it is a disservice to ruby.
As a beginner, trying to deploying a rails app to production from scratch is likely to drive you a bit crazy.