Felix Bünemann

I think it would make sense to use the ruby C API version for the directories, which would be 1.8 for ruby 1.8.x, 1.9.1 for ruby 1.9.1+, 2.0.0 for 2.0.x...

This is probably interesting to the discussion: [Introducing a semantic versioning scheme and branching policy](https://bugs.ruby-lang.org/issues/8835)

The following code returns the C API version: ``` ruby require 'rbconfig' puts RbConfig::CONFIG["ruby_version"] ``` On jruby this returns "1.9" while RUBY_VERSION returns "2.0.0", which might be because C-Extension support...

Isn't no gem separation between minor versions the point of the discussion? If upgrading rubies `gem pristine --all --only-executables` should do the trick. If sharing between rubyies with same API...

Yes, that would be nice. For now I'm using this patch with 0.3.8: ``` diff --- chruby/0.3.8/share/chruby/chruby.sh 2014-05-15 00:48:18.000000000 +0200 +++ chruby/0.3.8/share/chruby/chruby.sh 2014-05-15 00:39:08.000000000 +0200 @@ -44,14 +44,16 @@ eval...

Ah, that's nicer. I grepped through the rubygems source, and there seems to be an environment variable GEMRC that can point to additional gem config files, so it would be...

If you upgrade a debian system that's running eg. ruby-1.9.2-p0 as the system ruby to a newer release that runs eg. ruby-1.9.3-p194 you can continue using all your gems, cause...

Hmm, maybe it would make sense to just detect the rubygems version and fallback to the full version scheme if it's too old?

I'm probably misunderstanding you, but that's already returned by RUBY_VERSION, the patchlevel is stored in RUBY_PATCHLEVEL.

Ah, ok, so you mean the major releases like 1.9.2, 1.9.3, 2.0, 2.1, 2.2.