Wrongly referring ruby version instead of gem versions about spec

[eregon]

Agreed in general.
Although I think it may be OK to fix specific issues rather than to address the 192 cases when probably most of them work fine in practice.
IIRC some of the default gems did not have a VERSION constant (hopefully not a problem anymore).

their own versions which are unrelated to RUBY_VERSION.

That's not completely true, ruby/spec is meant to be run with the default gems of a Ruby release, and so e.g. default versions are always >= for a newer Ruby release (in version ordering).

[nobu]

• Many of the 192 cases are because of the promotion to default gems (matrix, net-ftp, prime).
• io-wait guards are because of Ruby's API addtions.
• socket is not gemified, and should be excluded from the list.

[nobu]

As for set/pretty_print_spec.rb (and set/pretty_print_cycle_spec.rb), should not test internal methods, I think.

[k0kubun]

Many of the 192 cases are because of the promotion to default gems (matrix, net-ftp, prime).

Off topic: If many of the default gem specs exist because we wrote them when it was not a gem, would it make sense to migrate such tests to the gem repository (and possibly hook the tests from the ruby/spec suite)?

Currently, ruby/spec is not executed in default gem repositories, and changes in such repositories often result in ruby/spec failures in ruby/ruby even if the gem's CI is passing (because it doesn't run ruby/spec). Unlike test-all, since other Ruby implementations can easily run the tests of gems, it seems redundant to have two different test suites once gemified.

[eregon]

Yes,we should probably move the specs of extracted stdlibs to their repo. I think it's a lot of work though. And it would need mspec releases (currently there is no compatibility needed in mspec), and we don't own the mspec gem (could be ruby-mspec).

[k0kubun]

Yes,we should probably move the specs of extracted stdlibs to their repo.

😍

I think it's a lot of work though.

I can migrate ERB as a starter and encourage other active folks to follow it. It never ends unless we start it 🙂

we don't own the mspec gem

I wonder if @brixen is open to adding you as a gem owner?

could be ruby-mspec

Agreed.