Ruby 1.[89].\d+ and beyond.

I've been thinking about how version numbers are restricting what we can do.
We are having difficulties releasing 1.8.x because x can only be in [6789]
before we run out of numbers.  Similarly, 1.9 will be the upper limit of
the 1.y series.

In version.h, somewhere in the 1.6 series (I've only looked at the
highest _TEENY versions for each release) we got some more constants:

#define RUBY_VERSION_MAJOR 1
#define RUBY_VERSION_MINOR 6
#define RUBY_VERSION_TEENY 8
#define RUBY_RELEASE_YEAR 2002
#define RUBY_RELEASE_MONTH 12
#define RUBY_RELEASE_DAY 24

which don't get passed through version.c to the Ruby API as far as I
can see.  There seems to be no reason why 1.4.x, 1.3.x can't have
these added. I've not looked at 1.2.x and below.  We'd need some
functionality added to version.c to allow direct access to those
numbers.

I'd suggest the following strategy:

  * Add these constants with appropriate values in backports to 1.4.x,
    and 1.3.x if that was a stable release series.  I was not in the 
    Ruby community then.

  * Promote RUBY_VERSION to a built-in Version class.  Then we can
    mixin comparable, which goes back at least as far as 1.3.x, and
    this would make version checking more flexible.  We could permit
    comparisons with Strings, and possibly tweak String so comparisons
    the other way behave sensibly.  That would need some debate.

  * Do all the above in such a way that ..._MAJOR, _MINOR and _TEENY
    can go beyond 9. [1]

At this point we would be left with old code that uses string
comparisons to check versions.  If this were running against
(theoretically) newly released 1.6.9, 1.4.7, and 1.3.8 versions, it
would still work correctly.  It would only break when 1.8.10 and
beyond come out, so we have some time to hunt down and kill those
bugs.

Releasing 1.3.8, 1.4.7 and 1.6.9 would allow those reluctant to
upgrade _MINOR versions to cope with a new versioning system.

To reach this point, we need:

  * Matz to approve this; 

  * Someone to craft this version handling stuff in C as per
    README.EXT.  (I don't do enough of that for me to do it quickly.
    But I don't mind attempting this.)

Else, if Matz doesn't approve of this then I don't have any other
solution to suggest at the moment.

The pressures for more version numbers come from these areas that I
am aware of:

  * People still want more documentation, and improvements to
    documentation.  There is little reward for working on that if
    it won't get released to those using stable ruby (most people).

  * People are working on speed improvements that many are keen to see.

  * It would be helpful to developers to have more version numbers
    between now and Ruby 2.0 (Rite).  [All those scary decisions about
    continuations, etc, can be deliberated.]

Does the above seem reasonable?  Is it even sane :-) ?

        Hugh

[1] We'll take the "Spinal Tap" jokes as read.