## mark a section (Learn more)

> > Charles Nutter suggested in the Ruby design meeting on June 4/5, that > > the value of RUBY_PLATFORM should reflect the layer just below Ruby > > code, which is really the implementation. That layer should be > > identified by RUBY_ENGINE instead. The value of RUBY_ENGINE has been > > agreed on but I don't believe it's been implemented anywhere outside > > of Rubinius. RUBY_ENGINE would be 'ruby' on MatzRuby, 'jruby' on > > JRuby, 'rbx' on Rubinius, and undefined as yet AFAIK on IronRuby, > > MacRuby, and MagLev. > > After more discussion, it would appear inescapable that we actually > need *three* standard values to distinguish this. One is > RUBY_PLATFORM, whose value needs to be defined. One is RUBY_ENGINE, > whose value has been defined. And the third is another constant that > would represent 'java', 'clr', etc. Essentially, the layer between the > OS+arch at the bottom, and the implementation at the top, just below > the Ruby code. > > We need a name for the new constant. We need to define it's contents. > And we need to define what RUBY_PLATFORM will mean. I am not sure why both cannot simply be codified into RUBY_PLATFORM? The two will always be interdependent anyway, and it would avoid the question of which is the "platform" and which is the "shim." It may also allow e.g. for JRuby to _not_ report the OS and hardware when the platform implements the Java specification without any deviation, if that is desirable over always including those details. With the specification that RUBY_PLATFORM should _always_ be regexp- or substring-matched, we can simply say the following: # MatzRuby RUBY_PLATFORM = "mips64-Plan9-edition4" # JRuby RUBY_PLATFORM = "java-mips64-Plan9-edition4" # Etc. If necessary for splitting the string or some other discourageable activity, the "shim" slot in the string could be "unknown," "none," "c," "posix" or something. It seems inadvisable to require specific formatting, though, since it will not apply the same everywhere. Any other information about the platform would be available through RbConfig or some other specific mechanism which can be used after the initial platform recognition has been done. So, my recommendation for the common constants: RUBY_ENGINE ------------- Single-word lowercased codebase name, "ruby," "rubinius," "jruby" and so on. RUBY_VERSION -------------- Version of the Ruby language implemented by the engine, as set by MatzRuby. A RUBY_VERSION of "1.8.6" means that any code that works on the 1.8.6 release from http://ruby-lang.org should work exactly the same on this engine. Same for any other version. RUBY_PLATFORM --------------- A string generally in the format currently used for RUBY_PLATFORM, with the exception that it may also contain the additional compatibility layer name like e.g. "java" or "java6" (as determined by the engine) for JRuby. #{RUBY_ENGINE.upcase}_VERSION ------------------------------- Freeform version identifier for the engine. For MatzRuby, the constant is the same, RUBY_VERSION, while RUBINIUS_VERSION could be "0.9.0-rc1" and other platforms are free to use "1.2," "some droll version name" or whatever happens to apply. For the time being, RUBY_PATCHLEVEL etc. could be simply matched to whatever the engine attempts to be compliant with, but I think it should be determined that added, changed or removed functionality must always be in a new Teeny version number. Patchlevels should be used exclusively for bugfixes in the future (and should only ever be checked by users or library authors to see whether the engine exhibits a certain bug or not.) In the long term, I would recommend that RUBY_VERSION 1. Be extended to four sections, e.g. "1.8.6.p114"; and 2. Be given as an Array rather than a String either directly or by adding a new constant. Versions should always be matched as far and only as far as possible: a system giving RUBY_VERSION == "1.8.6" should be matched by "1" "1.8" and "1.8.6" but not "1.8.6.111". Same rules would apply for the Array variant as well.

This paste will be private.