When using RBConfig to determine my ruby version, I get the "wrong" teeny version when using ruby 1.9.3:
# ruby -v
ruby 1.9.3p286 (2012-10-12 revision 37165) [i686-linux]
# ruby -rrbconfig -e 'puts RbConfig::CONFIG.fetch(%q(MAJOR))'
1
# ruby -rrbconfig -e 'puts RbConfig::CONFIG.fetch(%q(MINOR))'
9
# ruby -rrbconfig -e 'puts RbConfig::CONFIG.fetch(%q(TEENY))'
1
Using Ruby 1.8.7 - this works fine:
$ ruby -v
ruby 1.8.7 (2012-06-29 patchlevel 370) [x86_64-linux]
$ ruby -rrbconfig -e 'puts Config::CONFIG.fetch(%q(MAJOR))'
1
$ ruby -rrbconfig -e 'puts Config::CONFIG.fetch(%q(MINOR))'
8
$ ruby -rrbconfig -e 'puts Config::CONFIG.fetch(%q(TEENY))'
7
I know I can get patchlevel and use that a bit, but why is ruby 1.9.3 returning 1 as its teeny version?
Looks like Minor is just reporting on the library minor - ok. So all I am left with is the ruby_version string - better than nothing.
ruby 1.8 shows this:
and ruby 1.9.2-p320 this:
So I guess mystery solved.
Ruby has two concepts of version: The actual release version, and the "compatibility version". For all Rubies 1.9.1 -> 1.9.3, the compatibility version is
1.9.1
, because they are all backward compatible with the1.9.1
release.The
RUBY_VERSION
constant contains the release version number, but you will need to split the dots to get the MAJOR, MINOR, and TEENY if those values are important to you:That said, Ruby version numbers are specifically designed to be ASCII-comparable, so it is common to see code like this for simple version checks:
Patch level can typically be ignored, because there are no API changes in patch level releases, only bug fixes and security patches. Hope that helps!