> == FAQ
:The standard library is installed in /usr/local/lib/ruby/1.9.1
This version number is "library compatibility version". Ruby 1.9.2 is
mostly compatible with the 1.9.2, so its library is installed in the
directory.
This is insane. I have just had to explain 3 people on #ruby-lang why my error log has 1.9.1 in it if I am running purely 1.9.2.
This tangentially breaks the principle of least surprise. I can't see any good reason for doing this. This will result in unnecessary head aches during debugging for months to come.
It's surprising (though not unwelcome) to see that the only distro at the highest level of support ('Supported') is Debian 5.0 (i.e. Lenny). Some irony here: Lenny currently has Ruby 1.8.7 and 1.9.0 (as a distinct package - 1.8.7 is the default Ruby); Squeeze (Debian 6.0) has 1.8.7-p299 as a Ruby default and 1.9.1 for the 1.9 branch. Since Squeeze just froze, it is unlikely to release with 1.9.2 - though they may make an exception. Point being: the only distro that enjoys the fullest level of support has no stable version with 1.9.2.
OSX, Windows, FreeBSD, Solaris and Symbian make the next level ('Best Effort'), and all other Linux distros only come in at the third level ('Perhaps').
I respect the developers' frankness, and it's not something I have to worry much about, but the names of the support levels don't scream "use me on a multi-billion dollar project" for corporate folks.
We use Debian for the CI machine. CI failures are taken quite seriously, and we have a person maintaining this CI box. I believe that is why Debian is considered highest.
The next level of OS support are core developers that use that OS for work / home, but we don't have CI machines.
I think if we had more CI boxes, then more platforms could join the "highest level" support. I know there was a conversation on the Japanese dev list about this, and I can try to dig it up if people are interested.
What are your CI boxes running? The Hudson team used to have a number of Hudson slaves running various OSs and distros just building Hudson on-demand.
That cluster drifted away, but there are a lot of Hudson servers out there that are mostly idle, and people seem generally happy to donate the CPU time. I've got an Ubuntu one here that could run Ruby slave builds.
2) We have no process for people donating CPU time
I can translate the docs, but that still doesn't overcome the burden of running custom CI software. I'll email ruby-core about #2 because I'd really like to see more CI machines go up.
What features does chkbuild offer that Hudson doesn't? Should I put a feature request in?
If there's some stumbling block to adoption, it seems that switching the single CI box to Hudson, then utilizing the numerous Hudson boxes out there as slaves is quicker than trying to get people on board with chkbuild.
Now I'm wondering how you are taking "support" here. I didn't take it to mean "offer formal support for." That is, there's no phone number or email where someone will respond, is there?
When you say "these sort of projects", I assume you mean open source. When I look at Vim.org or Perl.org, they explain how to get source or binaries and install on various operating systems and distros. There's no differentiation in level of support or otherwise. This may be what you mean by "not supporting", but I found Ruby's explicit division of levels of support surprising.
Tenderlove's note explains things, but again I worry that the wording of the release notice may be off-putting to PHBs. Probably they are not Ruby's target audience - though I see plenty of discussion, books and conferences about Ruby for the Enterprise.
I don't mean to dwell on any of this in a bad way, and again I'm not complaining. I've never seen explicit divisions of support on something like Ruby before, so I posted.
No I mean support in the same sense you do. Their "supported" OS's are obviously just things they have access to, and know that it compiles & tests fine there.
E.g. they only have AIX 5 in "perhaps", that's only in the "Best Effort" category in Perl's case because a few dedicated individuals still build and test on it before release.
Thanks for the link. After reading that, I'm very suprised to see this for the 'Perhaps' category - given that every Linux distro other than Debian falls into that group:
We think Ruby works on it, however, we do not care about it.
I sometimes release Ruby even if there are issues on it.
The release part I get, but "we do not care about it" seems awfully dismissive. Maybe it came out differently than it was meant.
Right, but somewhat beside the point. That is, assuming you have Debian (at whatever level) and want 1.9.2, there are lots of ways you might get it. Backports is always a good option for newer things, compiled for stable. (In the case of Ruby, I would probably go with rvm first, but that's neither here nor there.)
But the irony is that Ruby says "This is the distro that has our highest level of support." while simultaneously that distro does not (out of the box) support 1.9.2. Just an odd thing, and it struck me. Tenderlove's explanation is perfectly reasonable, and I'm not criticizing. It's just ironic.
This is the first version where conformance to RubySpec was made a high priority. It now passes over 99% of the spec. This is great news for the community because it makes it much easier for alternative ruby implementations to remain compatible.
So, the revision number is very slightly different. Hard to say in this case whether that is worth uninstalling the one and installing the other. Probably not, but hard to say exactly.
With 1.9.2, the I18n internationalization module does not update available locales after loading more languages in the backend module. In my app we do this as a plug-in and since it can be done in run-time there may need to be some extra steps taken. I doubt this matters for 99% of the people here but just thought I'd give you a heads up if any of you move to 1.9.2 and use I18n dynamically.
Not until distros start shipping it. I don't know about Ubuntu because I don't really use it, but Fedora's still shipping with 1.8 and Fedora 14 will only be released in November.
At this point as a Rubyist the only thing you really need is rubygems (of any version) on your computer. gem install rvm and then rvm install RUBY_VERSION.
indeed. I stopped worrying about native system ruby version since moving to rvm. it is almost the only way to keep you sane while dealing with distros and ruby versions.
What's the best way to get rubygems with no other ruby packages on my system? Package manager, or dl and compile it?
My package manager wants to install ruby, irb, and a couple other 1.9.1 packages with it that I'm not sure I'll want after using rvm to install the 1.9.2 versions.
Go with whatever your distro provides as a default. RVM completely segregates your RVM Rubies from your system Ruby, so you're far better off with a "common" system Ruby install than you are trying to hack together a stripped down Ruby install. The package maintainers already know the platform specific idiosyncrasies you'll need to work around, so might as well leverage that. You may also encounter other software that expects a certain system Ruby environment on your system, so there's that too.
People still use Ruby packages from their Linux distribution? I've always compiled, especially since Debian cripples RubyGems. Either that or I use ArchLinux, which uses the actual stable version of the software.
I would speculate that anyone doing any real work in Ruby doesn't wait on the distro to provide it. I don't do that with Perl, I compile my own. I would imagine Rubyists are the same way too. Anyway, kudos to the Ruby folks.
Off-topic, but have you tried Gugod's Perlbrew for handling multiple Perl interpreters? It's like rvm, but for Perl. I've been using it for a bit with great results.
When I tried it (earlier this year), it wasn't quite like RVM. RVM is very versatile, powerful and polished. Perlbrew is getting there, but seems good only for particular limited ranges of use. Things I got used to with RVM weren't ready yet in Perlbrew. Various Perl versions wouldn't compile for me successfully. You can also compare the Synopsis of Perlbrew with the range of rvm commands and switches to get a feel for how much is missing in Perlbrew. I really wish Perlbrew gave me a good out-of-the-box experience, because it would be very handy for me, but that wasn't the case.
The most popular way (and easy, really) has always been to curl and compile yourself.
And these days RVM is growing up on production servers too, because it's really convenient if you have many apps each with the exact version it requires.
If it was any software but Ruby, I'd agree with you, but Rubyists tend to be into the cutting edge, as well as not using package managers to install Ruby. The conventional wisdom (at least for Ubuntu) has been "don't use apt, compile your own" for a while now. Or even better, use rvm.
Mr. Katz advised in multiple interviews/tweets (if I recall correctly) to wait for 1.9.2, and the community tends to listen. Rails 3 was tested against 1.9.2, not 1.9.1; this provided yet another reason to wait.
To add a few more details, it wasn't until 1.9.1 was out that "normal" people really started to look at it. There were quite a few changes that took time to be properly absorbed by the community (e.g. Internationalisation, see James Edwards Gray's blog).
Most gems also only started then to consider 1.9.1 as one of their targets, but it took some time. And anyway Rails was moving even more slowly.
Personally I've been using 1.9.1 for about a year now, but I don't make a living out of Ruby (or Rails) so it's understandable that people who need more reliable support waited a bit.
I can't speak for _everybody_, but I'm waiting to upgrade all of my sites that use Rails until Ruby 1.9.2 and Rails 3 both came out. I don't want to do two large updates, I'd rather do them together, and Rails 3 didn't support Ruby 1.9.1.
Also, there's just general conservatism; Ruby 1.9 was originally Ruby 2.0, but got renamed to 1.9 for reasons I don't quite remember/understand. 1.8 -> 1.9 is a much larger transition than the scheme would imply, roughly equivalent to the Python 2.6 -> 3 change, and we've seen how well that's gone. As time progresses, more people switch over, and each new release makes people decide it's finally time to re-write their scripts.
LOL, at first I thought you meant there was a new JIT compiler with 1.9.2 -- but you're right, this is good timing for those of us excited about Rails 3.
The last year we had a lot of "choice" due to the transitional period we were in. Hopefully by the end of the year that will be history.
Hurray! :)