Policy on Backwards Compatibility?

[blowmage]

m recently dropped Ruby 2.6 because it is EOL, and pinned the required Ruby to 2.7.
But, m is building against Minitest 4.x, who's last release (4.7.5) was on June 22, 2013.
And m does not specify a version of test-unit, and so the CI build uses the current version which is 3.5.5.
(For the record, the last release of test-unit 2.x (2.5.5) was on May 18, 2013.)

So I am wondering how much backwards compatibility m is interested in maintaining.
Is it worth building against 10 year old dependencies when it drops Ruby 2.6.0 which is only 5 years old.

tl;dr - I would like to either:

• Drop Minitest 4.x
• Add test-unit 2.x

What is everyone's opinion on this?

[Nakilon]

I'm always for keeping the compatibility. I believe the fact that gems maintainers drop the Ruby version support once it's declared as not supported by Ruby devs is just a confusion and misunderstanding. The gems should support old rubies as long as possible and never drop it just because of the rubylang news, because that's irrelevant.

[blowmage]

@Nakilon Thoughts on making changes like #105 that require newer rubies?

[Nakilon]

@Nakilon Thoughts on making changes like #105 that require newer rubies?

Sorry if I miss anything, I was generalizing anyway. But from docs I see that ripper is a thing in ruby for a long time already.

Personally, If a hypothetical addition wants several ruby versions upgrade I would want to see the rationale why it has to be done. As long as it works the same, I see no profit. Unless it's a security measure (that is unlikely a factor for software like this one).

[jeremyevans]

I don't see a point of dropping support for older Ruby or test library versions unless keeping support requires an undue maintenance burden.