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.
Keeping the symbol in RbConfig::CONFIG["STRIP"] won't help.
So that first suggestion is not going to help in practice.
Instead I think we could add a clean way to detect if there is an ABI version symbol which should be preserved.
For instance, setting RbConfig::CONFIG["ruby_abi_symbol"] to either "rb_abi_version" or nil.
Interesting, I think we should define RbConfig::CONFIG["abi_version"] (or "ruby_abi_version") if RbConfig::CONFIG["ruby_version"] it not always a proper ABI version.
Many places already assume RbConfig::CONFIG["ruby_version"] is the ABI version though, so that won't help much.
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).
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
I think it was always meant to allow to install multiple versions of the same version of Ruby, with possibly different configuration and what not. Unfortunately, the name is not always not expressive enough and not all Ruby maintainers know/remember why this variable is there and therefore it might be misunderstood/misused.
BTW I historically proposed to allow the ruby_version to not be used at all, e.g. to be an empty string. This unfortunately have not worked out. Instead, the ruby_version was made mandatory :/
I'm not sure why ABI version checking was removed for release versions of Ruby. In the development meeting for the feature, it was decided that we'll keep the same behaviour for development and release versions.
ko1: Will the ABI version be included in the release version? Or it is only for master branch?
peter: Curently, the check is done only for development branch
mame: I don't like a check only for development branch. When we try to create a tarball for release, something weird may happen.
ko1: If so, we can leave the ABI version for release branch.
Subject changed from RbConfig::CONFIG["STRIP"] should keep `rb_abi_version` and `rb_abi_version` should always be part of Ruby to RbConfig::CONFIG["STRIP"] should keep `ruby_abi_version` and `ruby_abi_version` should always be part of Ruby
A few extension libraries, to hide all symbols except for necessary to
load, hardcode the symbols to be exported in symbol list files for
linker without even checking by have_func. As a workaround for such
libraries, retain ruby_abi_version symbol always even in released
versions for now.
Updated by 
Updated by 
Updated by 
Updated by 
Updated by