Ruby comes automatically installed on OS X. I assume when you get a new Mac it comes with the latest stable release of Ruby. Do you have to update it yourself manually over time, or does it get upgraded automatically when you upgrade your OS?
I assume when you get a new Mac it comes with the latest stable release of Ruby.
No, it comes with whatever release Apple felt confident to support for the lifetime of the OS release.
Do you have to update it yourself manually over time, or does it get upgraded automatically when you upgrade your OS?
Those two are not mutually exclusive.
Yes, it does get upgraded automatically, in order to, e.g., patch security vulnerabilities. However, an OS vendor will generally avoid updating anything they ship as part of the OS as much as possible, since they generally guarantee backwards-compatibility, and the easiest way to guarantee backwards-compatibility for third-party code that you have no control over, is to just not change it.
For example, macOS 10.14.6, which is the current release of macOS and was released 4 weeks ago, ships with Ruby 2.3.7, which was released 18 months ago.
The last release of Ruby 2.3 was Ruby 2.3.8, and the Ruby developers stopped providing security patches to Ruby 2.3 6 months ago. (Note that Apple does still provide security patches for Ruby 2.3 as part of macOS, though.)
So, yes, it does get upgraded automatically, with e.g. security fixes, but if you want a different version than the one shipped with the OS, you have to install it yourself.
Short answer: No.
Long answer:
If you just want a taste of Ruby, then no, you really don't need to do anything.
If you want to use Ruby to do something non-trivial, like beyond a "Hello, world!" application, then yes you should update.
The best approach is to use a Ruby version manager like RVM or rbenv where you can get the latest version of Ruby, specific historical versions if necessary for testing, as well as alternate implementations like JRuby and Rubinius.
These version managers make it possible to have multiple versions of Ruby installed simultaneously and you can switch between at any time. You can even pin different projects at specific versions if they haven't been updated to work with the latest Ruby, a common problem with older code-bases.
This pattern plays out with any language, be it Ruby, Python, Perl, Node.js, C# or what have you. If you're doing serious development in those languages the first thing you do is install a version manager and the best version for your situation.
Related
I'm building my open-source game for MacOS in AppVeyor CI (which uses Catalina). I'm installing compiler and dependencies with brew and package it in .app format, and everything seems to work fine, except that when trying to launch resulting application in older MacOS versions (I only have High Sierra available for experimentation) I'm getting errors about newer MacOS version. I suppose if I can force Homebrew to install binaries for older MacOS versions, this would fix the problem, but how exactly can I do that?
I'm aware there's ability to build software from sources in brew, but I don't want to go that route considering I want my CI to be fast.
EDIT: To clarify, I'm trying to fix the following error: "You can't use this version of the application MyCoolGame with this version of macOS. You have macOS 10.13.6. The application requires macOS 10.15 or later."
Since time immemorial†, there have been two package managers for Macintosh computers: Homebrew and MacPorts. These projects are different in a variety of ways that some folks care about very deeply, and lots of people have opinions about which package manager is better. Once they all get tired of arguing, however, they usually acknowledge that Homebrew and MacPorts do basically the same thing, and return to more important topics like why tabs are better than spaces.
There is one particular difference between Homebrew and MacPorts which may interest you:
Homebrew supports the three most recent versions of macOS, which as of this writing is Monterrey, Ventura, and Big Sur. Homebrew can sometimes be installed on older operating systems too, but Homebrew's developers make zero effort to support these systems. The result is lots of breakage.
MacPorts also supports the three most recent versions of macOS. However, it also supports older versions of macOS on a "best-effort" basis. Notably, "best-effort" in this context is a term used to mean "a lot of f*cking effort." MacPorts actively maintains bespoke patches, hardware buildbots, and compatibility libraries for every version of macOS going back to OS X Tiger. (OS X Tiger, for those who don't know, is an operating system released in 2005. And 2005, for those who don't know, is a long forgotten age when phones were actually used to make phone calls, Zoom was just a TV series on PBS Kids, and Mug Cake hadn't been invented yet).
You stand at a crossroads. You have two choices. Do you:
Continue using Homebrew, with full knowledge that most packages will be broken and anything that is not broken will likely become broken in due course and at the least opportune time.
Use MacPorts, which actively supports your operating system and will continue to do so for the foreseeable future.
Choose wisely.
† aka the year of our lord 2009. That's basically the same thing, right?
I am frustrated: I want to yum install ruby and install Ruby 2.4.1 or 2.3.0. Instead it seems that I have to use RVM or rbenv to get any version after 2.0.0 and both of those tools require some arduous process.
Why is this so complicated? Shouldn't I be able to install Ruby with a single yum command and use '/usr/bin/ruby' like I would '/usr/bin/java'?
Things change between Ruby versions. With the release of Ruby 2.4.0, many gems and applications needed to be updated in order to be compatible without breaking, including JSON, Rails, Nokogiri and others.
Now, with a OS distribution, people usually expect two things:
relative stability over its release cycle, so, things which worked yesterday continue to work tomorrow
that all shipped packages are compatible to each other.
If the CentOS maintainers were to upgrade their Ruby version mid-release, they would have to ensure that all other software they ship which depends on Ruby is also compatible with this new version, probably by also updating it. This leads to a maintenance nightmare since, often, these updates also change features which break the first point of requiring stability.
Because of that distributions usually ship a single version of Ruby (or Python or Perl) and only fix necessary bugs by backporting the fixes to their versions. Major updates are usually only done with a complete new OS release. How often this happens depends on the distribution you use. CentOS/RHEL tend to be very slow, Debian is so-so, Ubuntu has slower-to-update LTS releases and quicker-to-update regular releases.
In general, you trade stability for bleeding edge. And for their base OS, most people running servers tend to favor stability.
To use a newer version of Ruby for your own apps, you can still use rbenv, RVM, or any of the other Ruby installers. You can install these custom Ruby versions along the OS version and configure your own applications to use these versions.
My application requires a GUI, and I was thinking of using GTK+ because by far it is the best library for Graphical User Interface. When I looked at the GTK+ page and went to Language Bindings, I found the following:
If Ruby is a good language and has a lot of programmers, why doesn't Ruby support GTK+ 2.14 and newer versions?
Because bindings to a more recent versions hasn't been yet written ? ;-)
Ruby-GNOME project is probably the most known implementation, see status of Gtk2. They also provide bindings for Gtk3, version 3.4 .
The differences between 2.12 and 2.24 are relatively marginal, there is no point it should you keep back at writing Gtk2 UIs in Ruby. The project is very active, latest commits was done a day ago.
Btw. linking on Linux/BSD systems is done to the major version so it'll run regardless minor subversion is currently installed. If there is some very specific feature added in latest versions you can write binding yourself, it's very easy. However as you are just at learning stage I'd bet you'll ever get in such situation in the near future.
I used Ruby many years ago and am back hopefully to stay. I recall from several years ago reading that odd-numbered releases of Ruby (eg. 1.9.1, 1.9.3, 1.9.5) are meant for development and that even releases (eg. 1.9.2, 1.9.4) are meant to be production stable. Is this (still) the case or is the latest "stable" as per the Ruby website the way to go?
I've never developed a project as grand as Ruby so I don't know if there are rules for releases that should be followed. Any enlightenment on this topic would be appreciated.
Thank you.
Yes, it is in fact true that odd-numbered releases were unstable in the past. (However, note that "odd-numbered" refers to the minor number, not the tiny number, i.e. 1.1.x, 1.3.x, 1.5.x and 1.7.x were unstable development releases.)
This was changed with Ruby 1.9 for a very simple (and very embarassing) reason: there are tons of Ruby scripts as well as shell scripts (including the scripts that the Ruby maintainers themselves use to automate the development, testing and releasing of Ruby) out there, which simply assume that the major version is a single digit. They would simply break otherwise, mostly because they did things like
if RUBY_VERSION > '1.6.3'
which fails for '1.10.0', because the string '1.10.0' is lexicograhically smaller than the string '1.6.3'.
As a result, it was decided to give up the distinction between odd-numbered and even-numbered releases, and make the next stable release 1.9, because that was easier than convincing everybody that their scripts are broken.
So, the 1.9.0-x series of releases corresponds to 1.9.x under the old numbering scheme (i.e. a series of development releases in preparation of the next release) and the 1.9.(x > 0) series of releases corresponds to 1.10.(x-1), i.e. 1.9.2 is really 1.10.1. (Well, except that 1.9.1 was a botched release, so it is more like a 1.10.0-pre and 1.9.2 is 1.10.0 and 1.9.3 is 1.10.1.)
Also, Ruby 2.0 is intended to be fully backwards-compatible, which means that it's really 1.12 ... does that clear up any confusion? :-)
So, in summary: Yes, it used to be true (but in a different way than you thought), but it is no longer true, and hasn't been true since the 1.7 series which ended with the release of Ruby 1.8.0 in August of 2003, over eight years ago.
Nope, that's not the case. I don't think it was ever the case with ruby. 1.8.6 and 1.8.7 were considered stable, as are 1.9.2 and 1.9.3.
You might be thinking of Linux kernels, that's how they do it there.
I've wanted to learn Ruby for some time and even started to learn a little bit. I then got distracted and for some reason went with Python. I have now however decided that even though my current project is in Python, I will also be learning Ruby and Ruby on Rails.
If somebody were to ask me what version of Python to start with I'd suggest 2.6 because 3 breaks compatibility with all the tutorials they would google. Knowing so little about Ruby, what version should I install on my computer? Is there a major difference between any two versions etc etc?
The version you learn is not that important.
While there will eventually be a shift from the more stable 1.8.x series, 1.9 isn't game breaking in a way where you will be disadvantaged.
Rails recommends version 1.8.7, so if you're going to be learning rails, I'd stick with that. This book is pretty good.
I don't think Ruby has had that many breaking changes - except 1.9 onwards. So any version in the 1.8.x should be fine.. pick the latest stable version.
Rails on the other hand has changed dramatically in Rails 2.
If you're going to be working in Windows, go with the current most stable one-click installer. At time of writing, that would still probably be the 1.8.6-26, although 1.8.6-27 is imminent. 1.8.7 is a small increment and I'm very uncertain about the status of 1.9.1 on the platform.
On OSX or other *nix varieties I'd be prepared to be somewhat more adventurous: the current production Rails release (2.3.2) is supposed to be 1.9.1-compatible (although that may not be the case with all third-party libraries for some time) and learning might be more entertaining with the latest version. It should run a good but faster, too.
Ruby 1.9 makes a few breaking changes, but not like Python 3. Any old Ruby tutorials should work just fine for 1.9. There's nothing like, for example, Python changing print and merging range() with xrange().
It really doesn't make that much difference. The core language hasn't changed a lot — 1.9 is just a lot faster and has gained some new features.
There are some changes that broke some libraries, but those have more to do with the finer implementation details rather than what you learn in basic tutorials, so it shouldn't hurt you. If you want to go with 1.8 for the better library support, that's fine. If you want to go with 1.9 for the better core features, that's fine as well. It doesn't make that much of a difference when you're just starting off.
If you're planning on building stuff that you don't release to the public, that makes use of lots of libraries, 1.8.7 or 1.8.6. If you're writing libraries that will be released to the public, please, please, please make sure they work in Ruby 1.9. Ruby 1.9 is a superior interpreter, but we're stuck with 1.8.x because so many libraries are incompatible with it right now.
http://isitruby19.com/
Learn the latest version. Current latest version is 2.4., but when higher versions are out, go for them immediately. Ruby team pays attention to only release finished work, you don't need to be afraid to install the newest one.