Dhaivat, not to nitpick but perhaps you should add a disclaimer to the bottom linking to the official installation page so no one bookmarks your page and tries to use your instructions later if they are out dated.
See
"External tutorials
Note that that any outside tutorials are NOT supported whether they work or not. Tutorials are great, however we have spent massive amounts of man hours debugging the installation process. Please use the install process(es) from this site only, as this is the only supported installation types and methods. "
So it's irresponsible to pipe some script off the internet into your shell, but it's completely fine to download some random gem and just require it straight away?
Or perhaps gem developers can not use hard dependencies i.e add_dependency('foobar' '1.2.3') and program based on the exposed interface. Maybe then versioning can become irrelevant and API breakage can be inferred (as can be done with c minus dl*, system and such).
How would you suggest getting them to do that, though? We've already got semver and the '~>' operator for rough version matching which should enable what you're saying. How do we get the people who aren't using semver to switch to it, or something equivalent?
Right, but again, how do we convince people to do this? The tools are there, but people aren't using them. I don't disagree that it would be better if they did, but I don't see a plan for increasing uptake.
If apt-get is the wrong way to install Rails, it sounds like a problem with Rails. Just whose responsibility is it to keep the version in the repos up-to-date anyway?
if you are willing to live with the gems at the versions they were released as whenever your distro was released and when you are willing to live with the subset of all gems that is part of your distributions repository, then apt-get is the perfect tool.
But the moment any of your apps introduce dependencies that cannot be met with your distribution, you are in trouble: maybe the gem needs a newer version of ruby?
Maybe the gem depends on a newer version of a gem that came with the system? Do you manually update that system gem? In that case, you might have just broken a distribution application depending on that older version (and not listing the version it needs, so the latest will be used.
As more and more time passes, the old, safe gem set becomes more and more restricting, increasing the temptation to use gem install instead of apt-get, but once you went down that path, you will open a whole shipping container of worms.
Remember, server distros update rarely. Up until last week, the latest Ubuntu LTS version you could get was from 2010. So much has happened in the ruby world sinc then that sticking to gems of that time could've really hard.
By using rvm, you decouple the gems and ruby your applications need from what the system needs, ensuring that te system remains stable, while you still can use the latest versions of the gems.
Apt-get install rails works fine, as long as you're doing it to apt-get install a distro-packaged rails app like redmine. It doesn't, and shouldn't, work for development. The distro's job is to supply end-user applications, not up-to-the-minute development tools.
Usually, a maintainer will step up and build packages for a given project. Be it one developer or a small team thereof, it's definitely not the entire community (and in fact can be unrelated to the community.) However, as distribution versions are end-of-lifed, packages stop receiving non-vital (AKA: security-only) updates, and that's not the fault of the Rails team or even of that maintainer.
I believe in the case of apt-get it's the responsibility of the Debian project. It's the same with other tools (yum, brew, macports).
Rails itself is normally installed via Rubygems (where it's updated directly by the Rails team), but the problem in this case lies with Ruby: for an up-to-date development/production environment you have to compile it by yourself or use something like RVM.
