Allow older rubies (with warning)

[marcandre]

I use mspec for backports.

I use it to run recent specs against old rubies that have had features backported.

I am in the process of using ruby/mspec instead of mspec gem because some specs no longer run (in particular because lambda? helper is new, not sure if there are other reasons).

So that the specs run, I need to tell ruby_version_is what the actual target is. There used to be SpecGuard.ruby_version_override=, which as been removed. I can go around that.

Also, mspec refuses to run older Rubies .. This PR is a small change to allow me to run mspec from older versions by turning an error into a warning / or overwrite the method altogether.

I imagine that the minimum Ruby requirement is constantly being bumped to minimize support. I'm not sure it is the right approach. mspec aims to be a simple and minimal implementation of rspec-like runner so that other Ruby implementation can hope to run it. Either mspec runs on older rubies (and this bumping is not necessary) or it doesn't (and this may make alternate implementations harder). FWIW, current master appears to run (at least for my purposes) in Ruby 2.1 (in Ruby 2.0 the private def don't work, I don't know if there are other actual issues) Hopefully this can be the case for some years to come...

[eregon]

The check was initially added in ruby/spec#460.
I forgot the actual reason, it's been 3 years, but I think Ruby 2.1 in general is quite buggy when it comes to keyword arguments and other things (but MSpec doesn't use keyword arguments).
Maybe it was partly for Etc.nprocessors: f64f5ec

I am in the process of using ruby/mspec instead of mspec gem because some specs no longer run (in particular because lambda? helper is new, not sure if there are other reasons).

Yes, the mspec gem is very old (2015), and there were several bugs I fixed in this repo (things around raise_error not noticing some error cases, and very confusing error messages, etc).

Either mspec runs on older rubies (and this bumping is not necessary) or it doesn't (and this may make alternate implementations harder).

The idea is alternative implementations should target a reasonably recent Ruby. I don't know of any alive alternative Ruby implementation supporting an out-of-life (as defined by CRuby) Ruby version.

Practically, I don't want to spend time to support EOL Rubies. If people want to run ruby/spec on EOL Rubies, it's possible, they just need an older ruby/spec and ruby/mspec: https://github.com/ruby/spec#specs-for-old-ruby-versions
Maintaining ruby/spec for EOL Rubies is a clear no, so then I adopted the same policy for MSpec.

This PR is fine, I'm OK to merge that.

If more fixes are needed, I'll evaluate on each PR, because the overhead of maintained long-dead versions can be significant (I remember trying to have Ruby 1.8-compat in RubyGems/Bundler, and that made me want to not contribute again until they bumped to a decent minimal version, which they did).

[eregon]

So that the specs run, I need to tell ruby_version_is what the actual target is. There used to be SpecGuard.ruby_version_override=, which as been removed. I can go around that.

One way is to override the VersionGuard::FULL_RUBY_VERSION constant like in https://github.com/oracle/truffleruby/blob/e020c89a8368ef2e1b996904f7becf65b375a47e/spec/truffleruby.mspec#L134-L142

I'd be OK to have some env var in MSpec to set it directly to the wanted version.

[marcandre]

One way is to override the VersionGuard::FULL_RUBY_VERSION constant

That's exactly what I did :-)

Thanks for the merge