What's the naming syntax for different versions of ruby and which should I gravitate towards for running scripts? i.e., using rbenv I can install the following versions of Ruby 1.9.3:
1.9.3-dev
1.9.3-p0
1.9.3-p125
1.9.3-p194
1.9.3-p286
1.9.3-p327
1.9.3-p362
1.9.3-p374
1.9.3-p385
1.9.3-p392
1.9.3-p429
1.9.3-preview1
1.9.3-rc1
So we have several different types:
dev
p#
preview#
rc#
I believe I can assume that p# is for build fixes to the spec, preview# is a preview of the version spec and a precursor to rc#, the release candidate of the spec. So, this leaves dev. Is the dev tagged build what I should use for scripting or is it the development branch? And should I try to keep the latest p# installed? What's the best practice here?
Ruby uses semver for naming versions.
Best practice is keep your ruby as up-to-date as possible using the latest p# build.
Current version is Ruby 2.0.0-p195
If you're stuck in 1.9.3 for compatibility reasons, the latest patch is 1.9.3-p459.
You can see these versions on the Ruby homepage
Related
I wanted to install Ruby 2.0.0 through rbenv for a project, because they list their Ruby version as 2.0.0. But there are a couple different versions listed there:
2.0.0-dev
2.0.0-preview1
2.0.0-preview2
2.0.0-rc1
2.0.0-rc2
2.0.0-p0
2.0.0-p195
2.0.0-p247
2.0.0-p353
2.0.0-p451
2.0.0-p481
2.0.0-p576
2.0.0-p594
2.0.0-p598
I guess 2.0.0-p598 is the most stable one, but what is the meaning of the following suffixes and what state of development do they represent?
dev
preview
rc (this is release candidate, I know this one)
pXXX
And can I use any of these for a Ruby project that uses Ruby 2.0.0?
2.0.0-dev is the ruby_2_0_0 SVN branch. The development (mostly merging fixed issues from trunk) of future 2.0.0 releases is done there.
2.0.0-previewX are preview releases that may contain some serious issues or features that'll never be a part of the first stable release (2.0.0-p0). For example, 2.1.0-preview1 had frozen string literals ('frozen'f) which were later replaced by an optimized String#freeze.
2.0.0-rcX is a release candidate. In the best case just bugs get fixed before the release, but in the (recent) past Ruby core developers did more like introducing an annoying warning.
2.0.0-pX are stable releases of 2.0.0. p means patch (level) and is followed by the number of commits since the first 2.0.0 stable release. Starting with 2.1.0 the version policy was changed and this number isn't much of interest to end users anymore.
To find out which is the most current version of the 2.0.0 series, you can visit the official downloads site.
I have multiple Rails apps from 3.2.14 to 3.2.18 in my development environment. I'm using Ruby 1.9.3 (yes, I know) for these apps and it's installed and managed via rbenv. I'm about to build a couple of new apps with Rails 4.1 and Ruby 2.1. My question is, what is the best way to handle installing multiple versions of Ruby using rbenv. Currently 1.9.3 is set to global, but I want different Rails apps (4.1) to use Ruby 2.1.
I guess I'm a bit behind the curve with Ruby management so I could use a hand here. Again, looking to have multiple Rails apps (different versions 3.2.14-4.1.x) and multiple Ruby instances to support each app.
I appreciate the help in advance.
Create a .ruby-version file in your application root directory and specify the ruby version you want. For instance, if you want one application to use 1.9.3 and the other 2.1.0, you'll have a .ruby-version file each in those two applications, specifying the version:
/application1/.ruby-version
1.9.3
/application2/.ruby-version
2.1.0
Update
For every installed version of ruby, you'll have a shims directory which will house all your gems for that particular version. When you switch between ruby versions, rbenv will simply set the environment variables to the one you select.
In the example above, I set the local ruby version for the directory ruby_cookbook to 2.1.2 and a gem list will only show gems installed for 2.1.2.
I also created a .ruby-version with ruby version 1.9.3-p547 in my try_stuff directory. As you can see, gem list only shows gems installed for 1.9.3.
The gems you install are specific to the current version of ruby.
If your project root has a .ruby-version file, your environment will automatically set the current ruby version to the one specified. So, yes, your production environment will need the version you mention in your .ruby-version. If you use git for source control, you can add that file to your .git-ignore and you won't see it in your prod version.
As the title says, can't find any documentation on what #something does in rvm use 2.0.0#something?
RVM is the Ruby Version Manager and its website is here: https://rvm.io/
The command rvm use 2.0.0#something tells RVM to change the setup of your current shell (terminal) so that you are using ruby 2.0.0. It also says to use the gemset named something. Gemsets are a feature of RVM that let you segregate your Ruby gems into different sets.
More information about gemsets is here: https://rvm.io/gemsets/basics
Suppose you are working on three parallel projects: one uses Ruby 1.9.3 and two use Ruby 2.0.0. Lets say:
Project A: Ruby 1.9.3
Project B: Ruby 2.0.0
Project C: Ruby 2.0.0
When you are working on Project A, you can just say rvm use 1.9.3, and it will set your current Ruby version to 1.9.3.
Problems arise when you are working on Project B or C, and they are using different versions of the same gem (lets say Project B uses httparty 1.0, and project C uses httparty 2.0).
In this case, rvm not only allows you to use different rubies by using rvm use, but also allows you to use different sets of gems with each Ruby (called gemsets).
So you can just say(When on project B): rvm use 2.0.0#project_b_gemset (and this will install all the gems required for project B as a different set)
When you are on project C, you can just say rvm use 2.0.0#project_c_gemset, and this will install all of the gems required for project C as a different set. And hence you can use different sets of gems with the same Ruby version.
Summing up:
rvm use ruby_version#gemset_version:
ruby_version allows segregation on the basis of Ruby versions and gemset_version allows you to do further segregation inside the same version of Ruby.
I have an application that depends on flexmock. For a number of reasons, I want this app to run on 1.8.7 to 2.0.0 and beyond, so far it worked really well. Since the app has a huge test suite it's been easy to maintain compatibility.
The only issue is flexmock. There is a bug in the older version of flexmock that I have to work around with a monkeypatch. The newer version of flexmock fixes the bug, but it only works on 1.9.3. The older version of flexmock that I use also gives test failures on 2.0.0 since it incorrectly records the number of method calls on classes like Time.
Is there a magic Bundler incantation that I can use to modify my development dependencies so that they come out with relevant versions for each version of Ruby I run on? Specifically so that it runs clean on Travis-Ci?
I do not version-control Gemfile.lock
You should put your flexmock versions in groups, and then when you bundle install you can exclude the groups you don't want, so:
group :ruby18 do
gem 'flexmock', ~> oldversion
end
groups :ruby19 do
gem 'flexmock', ~> newversion
end
and then when you run the app in 1.8 you can bundle install --without ruby19 and vice versa for ruby 1.9+. See more at http://gembundler.com/v1.3/groups.html
I know it's possible to get the Ruby version (e.g. "1.9.3") via the RUBY_VERSION constant. However, I want to know how to go about determining the exact version (e.g.: "1.9.3-p0"). The reason is that there is a bug that was not fixed in earlier versions of Ruby 1.9.3 that is working in later versions, and I want some code in a gem I'm working on to account for this.
There is a RUBY_PATCHLEVEL constant as well. So you can get your version string as
"#{RUBY_VERSION}-p#{RUBY_PATCHLEVEL}"
At least in the newest Ruby (2.3.0), there is also a RUBY_DESCRIPTION constant:
RUBY_DESCRIPTION
# => "ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-linux]"