Ruby 1.8.7 retired(ruby-lang.org)
ruby-lang.org
Ruby 1.8.7 retired
http://www.ruby-lang.org/en/news/2013/06/30/we-retire-1-8-7/
63 comments
If you want to play with Ruby and not Rails specifically, may I suggest a less monstrous framework, like Sinatra [1] or Ramaze [2]. Both come in one gem and have only one dependency - Rack (web server gateway).
You do not need a version manager to give Ruby a try. Although, it's a nice thing to have. If you decide to use one, you basically have 3 options: 1. rvm (most popular and bloated), 2. rbenv (simple), 3. chruby (even simpler).
If you can, I advise you to switch to Ruby 2.0. It's faster, got a lot of new features and it's becoming the default in the community.
Last piece of advice, do not mix up Ruby and Rails :)
[1] http://www.sinatrarb.com/ [2] http://ramaze.net/
You do not need a version manager to give Ruby a try. Although, it's a nice thing to have. If you decide to use one, you basically have 3 options: 1. rvm (most popular and bloated), 2. rbenv (simple), 3. chruby (even simpler).
If you can, I advise you to switch to Ruby 2.0. It's faster, got a lot of new features and it's becoming the default in the community.
Last piece of advice, do not mix up Ruby and Rails :)
[1] http://www.sinatrarb.com/ [2] http://ramaze.net/
If you are just trying to hack something together - don't worry. 1.8.7 has worked for a long time, and it will continue to do so for a while.
But if you are actually trying to build something to use long term - as crappy as it is to hear it now, it is not a great idea to use the system version of ruby. since it is likely as you get into ruby that you will have multiple projects which amy or may not require different subversions of ruby, you should always use rvm. it allows you to install multiple versions of ruby side by side.
also, check out https://github.com/tokaido/tokaidoapp
But if you are actually trying to build something to use long term - as crappy as it is to hear it now, it is not a great idea to use the system version of ruby. since it is likely as you get into ruby that you will have multiple projects which amy or may not require different subversions of ruby, you should always use rvm. it allows you to install multiple versions of ruby side by side.
also, check out https://github.com/tokaido/tokaidoapp
Really waiting for Tokaido to be real-life-ready, it is extremely promising.
A popular alternative to rvm is rbenv: https://github.com/sstephenson/rbenv
You might want to be careful: in OS X Mavericks, the default version of Ruby is 2.0.0p195. If you decide to upgrade, you'll have to go through this pain all over again.
If you're using Homebrew, you can install rbenv, ruby-build, and then use rbenv install to install a new Ruby version. Homebrew has its own version of Ruby, but it's the latest version and it's more maintainable to use rbenv or RVM to manage Ruby installations. It's sort of a pain, but once everything's set up, you won't have to think about it again.
If you're using Homebrew, you can install rbenv, ruby-build, and then use rbenv install to install a new Ruby version. Homebrew has its own version of Ruby, but it's the latest version and it's more maintainable to use rbenv or RVM to manage Ruby installations. It's sort of a pain, but once everything's set up, you won't have to think about it again.
You should install a ruby version manager. Most apps will specify the version in the project (.rvmrc or .ruby-version). If you have a ruby version manager and the required version installed, your system will switch automatically. Installing different versions of ruby is just a one liner.
rbenv setup guide: https://gist.github.com/jasoncodes/1223731
rvm instal ruby-1-9-3-p429
rbenv setup guide: https://gist.github.com/jasoncodes/1223731
I've got a theory that this is one of the reasons that system configuration/deployment aids are so popular right now. My experience has been that there's trouble with this every time I spin up a new Ruby project (particularly Rails) and/or move to a new system. It does tend to get better as you get into individual projects, though.
I found similar problems trying to get Rails running on OSX Lion. In the end I just went to using virtual machines running Ubuntu for development. I didn't bother with RVM, I just installed Ruby with apt-get and it was all really straight forward.
http://railsinstaller.org/ Made my life less of a headache when installing Ruby and Rails.
The whole ruby ecosystem is a nightmare for system administrators.
Ubuntu/Debian still ships with ruby 1.8.7 and 1.9.1p0 (which is evil I heard). In order to install a new ruby version one has to most likely compile it from scratch:
- Since there are no deb packages and there is no sane way to build deb packages
- Overriding system ruby has to be avoided since we manage the whole infrastructure with puppet (yes you can run it with 1.9x). Since we want to keep the ruby environment sane.
It get's really interesting once you use puppet to install an RVM ruby version. Which you then use to install $GENERIC_RUBY package (ie Gitlab) via Puppet.
I don't want to talk about the mess called "Puppet"...
It get's really interesting once you use puppet to install an RVM ruby version. Which you then use to install $GENERIC_RUBY package (ie Gitlab) via Puppet.
I don't want to talk about the mess called "Puppet"...
> The whole ruby ecosystem is a nightmare for system administrators.
It's getting better.
John Leach over at Brightbox has a ppa with up-to-date binary ruby packages: http://blog.brightbox.co.uk/posts/next-generation-ruby-packa... https://launchpad.net/~brightbox/+archive/ruby-ng-experiment...
I'd suggest giving them a go, and mirroring them inside your infrastructure if they work for you.
It's very annoying that checkinstall doesn't Just Work for recent ruby builds. If it did, I'd suggest that every time.
> It get's really interesting once you use puppet to install an RVM ruby version.
Yeah, don't do that.
It's getting better.
John Leach over at Brightbox has a ppa with up-to-date binary ruby packages: http://blog.brightbox.co.uk/posts/next-generation-ruby-packa... https://launchpad.net/~brightbox/+archive/ruby-ng-experiment...
I'd suggest giving them a go, and mirroring them inside your infrastructure if they work for you.
It's very annoying that checkinstall doesn't Just Work for recent ruby builds. If it did, I'd suggest that every time.
> It get's really interesting once you use puppet to install an RVM ruby version.
Yeah, don't do that.
>> It get's really interesting once you use puppet to install an RVM ruby version.
> Yeah, don't do that.
Why not? Puppet-RVM (https://github.com/blt04/puppet-rvm ) works very well. And puppet is basically a system documentation. Since it's clear what's installed on the machine.
> Yeah, don't do that.
Why not? Puppet-RVM (https://github.com/blt04/puppet-rvm ) works very well. And puppet is basically a system documentation. Since it's clear what's installed on the machine.
First, you're introducing deployment-time dependencies on network resources you don't control. The worst time to discover just how bad an idea that is is when you've just had a critical server go pop while rvm.io (for instance) is having DNS problems, and you've got clients, bosses and clients' bosses breathing down your neck to fix it.
Second, it implies you've got build tools installed on your production machines. That's bad for security.
Third, I've seen RVM screw up too much to trust it. It's got far too many moving parts, and so far I haven't found anything I need which it does that isn't done better by some other simpler tool.
Second, it implies you've got build tools installed on your production machines. That's bad for security.
Third, I've seen RVM screw up too much to trust it. It's got far too many moving parts, and so far I haven't found anything I need which it does that isn't done better by some other simpler tool.
Isn't it more Ubuntu/Debian's fault for shipping outdated versions of ruby than it is the ruby ecosystem's fault for simply having older versions?
Nope. Ubuntu and Debian are not at fault. They have to pick a version of Ruby which runs the user applications that Ubuntu and Debian package, which will be kept working throughout the support period of the OS release. Everything else is secondary. They don't get to upgrade versions half-way through the release cycle, either.
This is why it's not realistic to expect to use the system ruby for development: that's not what it's there for.
It's also worth noting that the version of Ruby in current Debian Stable (which is 1.9.3-p194) will in all likelihood be deprecated by ruby-core 2 years before the next Debian Stable release. Again, this is fine for Debian, because they have taken on the responsibility of keeping working the user applications which rely on the system ruby.
If you're complaining about the system ruby being so out of date that you can't develop applications on it, you're doing it wrong. The system ruby isn't for you.
This is why it's not realistic to expect to use the system ruby for development: that's not what it's there for.
It's also worth noting that the version of Ruby in current Debian Stable (which is 1.9.3-p194) will in all likelihood be deprecated by ruby-core 2 years before the next Debian Stable release. Again, this is fine for Debian, because they have taken on the responsibility of keeping working the user applications which rely on the system ruby.
If you're complaining about the system ruby being so out of date that you can't develop applications on it, you're doing it wrong. The system ruby isn't for you.
Ubuntu/Debian does not ship with Ruby 1.9.1. They ship with Ruby 1.9.3 under the name of "ruby-1.9.1" because they are ABI compatible.
Ah yes, I was confused by the ABI level. They ship with 1.9.3p0 which you shouldn't use. The currently recommended version is 1.9.3p392 or p194...
Debian Wheezy (current stable) ships with Ruby 1.9.3-p194 + various patches [1].
[1] http://packages.debian.org/wheezy/ruby1.9.1
[1] http://packages.debian.org/wheezy/ruby1.9.1
Ah yes, we're currently running Ubuntu 12.04 LTS.
ubuntu 13.04 is ruby 1.9.3p194 which i believe was the default for 12.10 as well
So is Apple finally going to update the version of ruby that comes already installed on osx?
Mavericks ships with 2.0.0
Yup it's a shame an operating system released as early as this year (mountain lion) came with 1.8.7 because it will be around for quite a while. We recently had to make the difficult decision to continue support of it in a new release because of CentOS, Mountain Lion etc...
At least 2.0.0p195 is indeed in Mavericks.
At least 2.0.0p195 is indeed in Mavericks.
Are there people that do programming on macs not use tools like macports or homebrew?
You are right, I'm pretty sure everyone who is a professional programmer uses homebrew, it's amazing.
However, coding to 1.8.7 lets those who aren't hardcore rubyists currently enjoy a gem they may otherwise not be able to without having to deal with or even know about rvm or rbenv.
However, coding to 1.8.7 lets those who aren't hardcore rubyists currently enjoy a gem they may otherwise not be able to without having to deal with or even know about rvm or rbenv.
There's gentoo/alt and fink which predates DarwinPorts. I'm sure there is even a pkgsrc user out there. I've occasionally used this one called make. It's sort of a meta language to homebeer. In fact it comes in two flavors pmake and gmake. =P
No more RVM! Fantastic news!
Please don't let that tempt you to use system Ruby. You should always build your own, especially on a system like OS X.
System Ruby is not there for you, it's there for the system to make use of (and yes, OS X does ship with quite a few Ruby scripts and a couple of Rails applications). Apple makes no guarantees of keeping this Ruby up to date.
System Ruby is not there for you, it's there for the system to make use of (and yes, OS X does ship with quite a few Ruby scripts and a couple of Rails applications). Apple makes no guarantees of keeping this Ruby up to date.
What are the Rails applications OSX ships with? I have never heard of or noticed this before.
I don't know what "vanilla" OSX ships with, but I've seen references to Rails pop up in logs in Console.app for my OSX Server when I was screwing with replacing their Postgres db with my own.
PSA: Do not use system Ruby - http://robots.thoughtbot.com/post/54109839209/psa-do-not-use...
Correct.
Don't use rvm or rbenv on your production Linux boxes. Use packaged Ruby there.
Don't use rvm or rbenv on your production Linux boxes. Use packaged Ruby there.
Er, why not? rvm was originally made for production use!
I've used rvm in production for major sites for years with no problems whatsoever, in fact I believe it is best practise. Do you have any reasons for your preference for packaged ruby?
I've used rvm in production for major sites for years with no problems whatsoever, in fact I believe it is best practise. Do you have any reasons for your preference for packaged ruby?
Best practice says production boxes shouldn't have compilers installed.
Install compilers on one machine, build Ruby, package it up as a deb/rpm/whatever, distribute to other machines.
Yep, that's the idea.
Sounds like an awful lot of work for no good reason I can think of.
You'll need a compiler, anyway, once you start trying to use any number of libraries requiring compiled C extensions.
"No compilers on production!" might be true elsewhere but I can't see any reason it applies for ruby deployments.
You'll need a compiler, anyway, once you start trying to use any number of libraries requiring compiled C extensions.
"No compilers on production!" might be true elsewhere but I can't see any reason it applies for ruby deployments.
> Sounds like an awful lot of work for no good reason I can think of.
Perfectly reproducible deploys and shutting down attack vectors are both very good reasons.
> You'll need a compiler, anyway, once you start trying to use any number of libraries requiring compiled C extensions.
Only if you're doing `gem install` in production. Guess what? That's not a particularly good idea either.
> "No compilers on production!" might be true elsewhere but I can't see any reason it applies for ruby deployments.
Ruby isn't special, or magic. It doesn't get a free pass "just because." If you've got reasons it should be exempt from the best practices that have been learnt elsewhere, let's hear them.
Perfectly reproducible deploys and shutting down attack vectors are both very good reasons.
> You'll need a compiler, anyway, once you start trying to use any number of libraries requiring compiled C extensions.
Only if you're doing `gem install` in production. Guess what? That's not a particularly good idea either.
> "No compilers on production!" might be true elsewhere but I can't see any reason it applies for ruby deployments.
Ruby isn't special, or magic. It doesn't get a free pass "just because." If you've got reasons it should be exempt from the best practices that have been learnt elsewhere, let's hear them.
In the real world, we don't have unlimited time, so we have to try to balance effort required versus the outcomes we desire in order to get the best "bang for buck" out of our time. Your suggestions are incompatible with this imperative.
> Perfectly reproducible deploys and shutting down attack vectors are both very good reasons.
No they're not. Firstly, I already have good enough deploys. Secondly, the attack vector you're talking about - having a compiler installed (!) - is almost not worth mentioning and certainly does not justify the huge extra effort. We're running a business here.
> Only if you're doing `gem install` in production. Guess what? That's not a particularly good idea either.
Says you, and pretty much only you. Anything else is a massive inconvenience. Everyone does this. It may not be "perfect" but again, we are running businesses here.
> If you've got reasons it should be exempt from the best practices that have been learnt elsewhere
No, it doesn't work like that. "Best practice" does not mean a blind adherence to some decade-old set of irrelevant rules ahead of all practical operational priorities. What the ruby community has is a practical balance - workable, efficient, fast. What you suggest rings of a disconnected IT department with no incentive to make life easy for those trying to iterate fast. It smacks of ass-covering and excuses; I know it well.
You've not made any points I find compelling in the least. Anyway, I don't wish to argue about it, I simply wish to point out, to any others reading this, that your opinion on best practise for ruby deployments is controversial, to say the least.
Anyway, I doubt you've actually done any deployments at all in accordance with the ridiculous "best practise" you've outlined. I doubt anyone has. I, on the other hand, have had great success with my approach, as have countless others. As usual, the armchair quarterback has any number of wise-sounding criticisms, but is not actually in the game.
> Perfectly reproducible deploys and shutting down attack vectors are both very good reasons.
No they're not. Firstly, I already have good enough deploys. Secondly, the attack vector you're talking about - having a compiler installed (!) - is almost not worth mentioning and certainly does not justify the huge extra effort. We're running a business here.
> Only if you're doing `gem install` in production. Guess what? That's not a particularly good idea either.
Says you, and pretty much only you. Anything else is a massive inconvenience. Everyone does this. It may not be "perfect" but again, we are running businesses here.
> If you've got reasons it should be exempt from the best practices that have been learnt elsewhere
No, it doesn't work like that. "Best practice" does not mean a blind adherence to some decade-old set of irrelevant rules ahead of all practical operational priorities. What the ruby community has is a practical balance - workable, efficient, fast. What you suggest rings of a disconnected IT department with no incentive to make life easy for those trying to iterate fast. It smacks of ass-covering and excuses; I know it well.
You've not made any points I find compelling in the least. Anyway, I don't wish to argue about it, I simply wish to point out, to any others reading this, that your opinion on best practise for ruby deployments is controversial, to say the least.
Anyway, I doubt you've actually done any deployments at all in accordance with the ridiculous "best practise" you've outlined. I doubt anyone has. I, on the other hand, have had great success with my approach, as have countless others. As usual, the armchair quarterback has any number of wise-sounding criticisms, but is not actually in the game.
I'll give this a read, thanks for sharing.
I like RVM - and I donated $5 to the maintainer. I guess it's better to not always need it, but it's saved me a lot of time.
I agree, RVM is a fantastic tool and a god send. Tremendous job by the creator. I just always felt that it was 'odd' to have to install N version of Ruby just to work on a particular project.
RVM is a very impressive collection of monstrous hacks jammed into a kitchen-sink tool to achieve a set of ends that can be better met in other ways. It's worth learning enough about how the Ruby environment fits together to figure out how. It's great to get learners off the ground (assuming it works first time), but if you're doing ruby seriously then I reckon part of your education should be how to get off it as soon as possible.
I was about to ask the same thing about Red Hat Enterprise Linux (or CentOS).
Matz said a few days ago at the European Ruby Conference that the 1.8 -> 1.9 transition was a 'once in 20 years event' and that Ruby would not break backwards compatibility this way again until a theoretical 3.0 release which wouldn't come out for a very, very long time.
I love how he apologizes for his "limited" English and then drops a line like "[Ruby] 1.8.7 was the last scion of that clan." If that's "limited", then we're all in trouble.
That's exactly why I went with Django/Python instead of RoR/Ruby.
I have no problem with keeping software up-to-date but I don't want to make that a main task because some "cool" kids easily get bored and keep phasing out stuff which break production apps and/or causes security issues.
I have no problem with keeping software up-to-date but I don't want to make that a main task because some "cool" kids easily get bored and keep phasing out stuff which break production apps and/or causes security issues.
If you "have no problem with keeping software up-to-date" then don't complain about these type of changes. As developers we either are responsible about version policies or we're not. Let's take Ruby 1.8.7 as an example:
If you were responsible you went through several patchlevels of Ruby 1.8.7, you're using the latest release (to fix security issues if nothing else) and you had five years to migrate to 1.9 (which most likely meant changing nothing in your code, just testing it).
If you were not responsible and you're running on something different to the latest patchlevel version then you're already running on faulty/unsecure software. Killing support upstream (again, after five years!) is not likely to change whatever you were [not] doing.
PS: Please don't refer to people like the ruby-core team as "cool kids who easily get bored". We all have our biases but name-calling doesn't add anything useful to discussions.
If you were responsible you went through several patchlevels of Ruby 1.8.7, you're using the latest release (to fix security issues if nothing else) and you had five years to migrate to 1.9 (which most likely meant changing nothing in your code, just testing it).
If you were not responsible and you're running on something different to the latest patchlevel version then you're already running on faulty/unsecure software. Killing support upstream (again, after five years!) is not likely to change whatever you were [not] doing.
PS: Please don't refer to people like the ruby-core team as "cool kids who easily get bored". We all have our biases but name-calling doesn't add anything useful to discussions.
> and you had five years to migrate to 1.9
Given that you were at the project right from the start and allowed to spend time necessary. It's funny to hear people moan on the one hand about corporate that use Java EE or even Cobol but on the other hand refuse to accept that in order for their software to be usable, it needs to be stable in some senses.
Given that you were at the project right from the start and allowed to spend time necessary. It's funny to hear people moan on the one hand about corporate that use Java EE or even Cobol but on the other hand refuse to accept that in order for their software to be usable, it needs to be stable in some senses.
When you joined a project is irrelevant. If you were hired two days ago and only found out about this now: tough luck, you have some work to do [0]. Even "stable", older platforms like Cobol have to deal with this (Micro Focus makes money off it with products like their Cobol set of tools (http://www.microfocus.com/mcro/cobol/index.aspx) [1]).
[0] Or maybe not. Your non-core [2] apps that run on 1.8.7 will still work tomorrow. Most of these applications are internal too so the risk is even less.
[1] There's almost always a 3rd party vendor who'll take advantage of a situations like this. They will make it your life easier and they'll charge you accordingly. See http://railslts.com/ for another example.
[2] If the applications that are putting the food on your table are running in an environment where no one thinks about this kind of stuff, then maybe it's time to take the wheel and start educating your team on why this is important.
[0] Or maybe not. Your non-core [2] apps that run on 1.8.7 will still work tomorrow. Most of these applications are internal too so the risk is even less.
[1] There's almost always a 3rd party vendor who'll take advantage of a situations like this. They will make it your life easier and they'll charge you accordingly. See http://railslts.com/ for another example.
[2] If the applications that are putting the food on your table are running in an environment where no one thinks about this kind of stuff, then maybe it's time to take the wheel and start educating your team on why this is important.
[0] Precisely.
[1], [2] After all management does such decisions. I have warned people face-to-face, via E-Mail, through all possible channels. So if things go wild, it's their problem, not mine.
[1], [2] After all management does such decisions. I have warned people face-to-face, via E-Mail, through all possible channels. So if things go wild, it's their problem, not mine.
You went with Django/Python eh?
Which Python exactly? 2.6? 2.7? 3.3? That a Python user of all people would whine about lack of stability and consistency is extremely funny.
Which Python exactly? 2.6? 2.7? 3.3? That a Python user of all people would whine about lack of stability and consistency is extremely funny.
Django 1.5 (latest stable version) requires Python 2.6.5 or above, so it doesn't matter.
Doesn't Django/Python have its own version headaches? (Python 3 came out 5 years ago, but Django didn't officially support until February of this year)
Phasing out old version of the underlying language isn't uncommon. For example, Oracle doesn't even support Java 6 anymore, which was released in 2007.
Phasing out old version of the underlying language isn't uncommon. For example, Oracle doesn't even support Java 6 anymore, which was released in 2007.
I think the difference is that Python had a much more realistic plan for the backwards incompatible changes. The fact that the transition will likely take the better part of a decade is a _feature_, not an issue (and there will be supported versions of 2.x throughout that time).
I always have respect for people using Python to make a living. But it seems that you don't use the language as your main tool (maybe as a toy). Please, do respect all other's work even if you don't use (or hate) it.
Yeah, there's nothing like the Python 2 to Python 3 transition going on there for the umteenth year.
The difference is, the Python developers had a realistic view of what this transition would look like, and it's very intentional that it will have taken the better part of a decade by the time all is said and done.
Seriously I thought ruby was supposed to be a beacon of simplicity? Someone please tell me there's a light at the end of this tunnel.
Edit: Some folks have mentioned getting the RVM. I think I was unclear when I just said I've been fighting with ruby versions - I meant that all of this was done with RVM/gems/bundle/etc, but it's still been a p.i.t.a.