From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-2.9 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 396771F453 for ; Sat, 27 Apr 2019 19:49:18 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 863D9120938; Sun, 28 Apr 2019 04:49:12 +0900 (JST) Received: from o1678916x28.outbound-mail.sendgrid.net (o1678916x28.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 5F428120910 for ; Sun, 28 Apr 2019 04:49:10 +0900 (JST) Received: by filter0124p3las1.sendgrid.net with SMTP id filter0124p3las1-21778-5CC4B235-27 2019-04-27 19:49:10.040127468 +0000 UTC m=+170976.436578956 Received: from herokuapp.com (unknown [3.88.222.166]) by ismtpd0027p1iad2.sendgrid.net (SG) with ESMTP id Gh1BPwZEQEWNLGXm7Je6wg for ; Sat, 27 Apr 2019 19:49:09.829 +0000 (UTC) Date: Sat, 27 Apr 2019 19:49:10 +0000 (UTC) From: eregontp@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 67928 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15791 X-Redmine-Issue-Author: headius X-Redmine-Sender: Eregon X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: =?us-ascii?Q?KippOI8ZHtTweq7XfQzW93937kJ4QNWwSBuHnaMEcr1N1eHHC9x9nHQ3kRiYGn?= =?us-ascii?Q?PIeOrlfE368vdSwTa+Jmb=2Fc7FoCVSQNnM7I3XDi?= =?us-ascii?Q?QQdRL1ZfsJTn3y575g8d4beJTCtwKjN=2FxqJLwGw?= =?us-ascii?Q?oEuQ6qWouyvkkJNFdTe69HLX5ZXYvX655g7nge8?= =?us-ascii?Q?vKCeYv3QOHKidApyjwYU9nuY=2FCvQRAiDmtg=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 92445 Subject: [ruby-core:92445] [Ruby trunk Bug#15791] Clarify reason for RbConfig's ruby_version not reflecting "teeny" value X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #15791 has been updated by Eregon (Benoit Daloze). Indeed, AFAIK it's the ABI version. MSP-Greg (Greg L) wrote: > If the version with 'teeny' was used, one would be recompiling extension gems everytime a 'teeny' release was done? Which IMHO is a safer thing to do, but I suppose some people disagree and it depends on the point of view :) FWIW, I created https://github.com/postmodern/chruby/pull/410 so `chruby` would have a set of gems per installed Ruby version, even if `RUBY_VERSION` or `RbConfig::CONFIG["ruby_version"]` doesn't change for alternative Ruby implementations between two releases. ---------------------------------------- Bug #15791: Clarify reason for RbConfig's ruby_version not reflecting "teeny" value https://bugs.ruby-lang.org/issues/15791#change-77796 * 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/