Issue #19289 has been updated by Eregon (Benoit Daloze). vo.x (Vit Ondruch) wrote in #note-3:
Just FTR, don't forget that `ruby_version` can be arbitrary string: https://github.com/ruby/ruby/blob/90a80eb076429978e720e11fb17a3cbb96de3454/c...
Interesting, I think we should define `RbConfig::CONFIG["abi_version"]` if `RbConfig::CONFIG["ruby_version"]` it not always a proper ABI version. That said this kind of configuration is IMHO silly, changing it is basically guaranteed to break things, so a better way would be remove such configuration since it doesn't work properly (e.g. can reuse gems of another Ruby version). ---------------------------------------- Bug #19289: RbConfig::CONFIG["STRIP"] should keep `rb_abi_version` and `rb_abi_version` should always be part of Ruby https://bugs.ruby-lang.org/issues/19289#change-100896 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- From https://github.com/grpc/grpc/pull/31970 and https://github.com/redis-rb/redis-client/issues/58 First, I think we could add `-K rb_abi_version` to `RbConfig::CONFIG["STRIP"]` so it's automatically kept if `RbConfig::CONFIG["STRIP"]` is used (and that should be used if one strips any native extension). Second, I think it would be much better if the symbol is kept also for releases. The check could be kept too for safety (e.g., it can detect Ruby 3.3.0 gems used by Ruby 3.2.0), the value of `rb_abi_version` would just be the same as `RbConfig::CONFIG["ruby_version"]`, i.e., 3.2.0 for Ruby 3.2.x. Any difference between dev and release builds is a risk of not properly testing the release, and there is proof here that removing the symbol in releases causes troubles. Doing both of these would avoid complex and brittle logic upstream as in grpc and redis-client to deal with the new symbol. cc @nobu @peterzhu2118 -- https://bugs.ruby-lang.org/