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.
Related
I'm setting up the GemFile following some tutorial.
If an older version of a gem specifies its dependency as rake ~>10.3 on rubygems.org
does that mean a later version of rake won't work with this gem?
rake ~>10.3 means: 10.3.0 <= version < 11.0.0. The dependency constraint is not saying that rake must be exactly version 10.3.0.
The only thing I can say with certainty is that the bundle will refuse to install unless it contains a version of rake in that range.
Would the gem actually work with a later version of rake? Maybe. It depends what the code actually does! The old version of this gem was probably (?) written before rake v11.0.0 was released, therefore there was no way of knowing, at the time, whether or not it would be compatible.
You could create your own copy of the old gem version and try loosening/removing the dependency constraint, but I wouldn't recommend it; it's best to just upgrade all code to use newer (ideally the latest) versions, or downgrade other libraries for compatibility if absolutely necessary.
Gem dependency is a case-by-case basis. There is no possible way to say that any gem will or won't be backwards compatible, you have to test. The "closer" the version is, the more likely it is to be compatible, but this is in no way a rule that you can go by or trust.
In addition, I don't know if you are understanding the syntax of that either. ~> 10.3 does not mean that rake must be version 10.3. It is a slightly confusing operand, but limits the version to a subset of versions.
I'm just trying to use the simple career_builder gem and just get it imported by running the simple script:
require 'career_builder'
puts 'Hello world!'
and yet get the following error: /Library/Ruby/Site/2.0.0/rubygems/dependency.rb:315:in 'to_specs': Could not find 'activesupport' (~> 2.3.5) - did find: [activesupport-4.2.1,activesupport-3.1.12,activesupport-3.0.3] (Gem::LoadError)
I installed the gem with gem install career_builder and ran bundle install and even updated activesupport to the most recent version, but for some reason, the program can't find the newer version of activesupport. Does the gem require version 2.3.5?
http://guides.rubygems.org/patterns/
The ~>or 'twiddle-waka' is a ruby gems shortcut to specify the earliest version of the gem you can use without letting you go up to the next major release.
Your gem is being a bit unorthodox and also specifying a patch level.
So the gem_specification you're working with (activesupport' (~> 2.3.5)) really means minimum version of 2.3.5 maximum of the last patch released before 2.4.0.
The activesupport versions you have installed are all for subsequent major releases and won't work. Install something between 2.3.5 and 2.4.0 and you should be good to go.
Yes. It does require Active Support version >= 2.3.5 and < 2.4.0. All of your Active Support versions are > 2.4.0.
~> is called the spermy operator. See Meaning of tilde-greater-than (~>) in version requirement?
The gem has not been updated in 4 years, so it uses Rails 2.
FWIW, I don't think you'll have much luck getting it to work, so you may want to find a similar gem that works with Rails 4 and has been updated within the last few months.
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.
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
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