> > 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.