Issue #15791 has been updated by vo.x (Vit Ondruch).


ruby_version is user configurable variable:

https://github.com/ruby/ruby/blob/trunk/configure.ac#L3663

It was introduced to make possible parallel install e.g. two Ruby 2.6.0 side by side. Later somebody start to interpret it and add it different meanings, but it was never correct thing to do, therefore I would suggest against using ruby_version for anything meaningful. I tried to have this resolved by #11002, but the result was never satisfactory.

----------------------------------------
Bug #15791: Clarify reason for RbConfig's ruby_version not reflecting "teeny" value
https://bugs.ruby-lang.org/issues/15791#change-78078

* Author: headius (Charles Nutter)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: all
* Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN
----------------------------------------
I did not realize that MRI always reports `RbConfig::CONFIG['ruby_version']` without the "teeny" value. Instead, it makes it always 0:

```
$ rvm ruby-2.6.2 do ruby -v -e 'p RbConfig::CONFIG["ruby_version"]'
ruby 2.6.2p47 (2019-03-13 revision 67232) [x86_64-darwin18]
"2.6.0"
```

This seems like a bug to me. It is a visible behavior because several package-management systems (RubyGems, Bundler, stuff in Ruby switchers like RVM) use this value, rather than RUBY_VERSION, to set up directory paths.

I believe it should reflect the full, accurate version, but I have not been able to find any discussion about why it does not do so.



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>