Compatibility with parallel_tests v5?

[pboling]

New releases of parallel_tests a few days ago:
https://github.com/grosser/parallel_tests/tags

[ilyazub]

Thanks @pboling! What are the features of parallel_tests v5 you want to use?

Nah, I'd rather stay with the most compatible parallel_test version. In v5.0.0 they dropped Ruby 3.0 and 3.1 support. I don't think we can reject that significant user base.

Previously I updated parallel_tests to a higher version for no good reason and it introduced issues in Rubygems (they use turbo_tests).

[pboling]

My need is to not drown in tech debt by letting versions get terribly out of date. I think perhaps simply unrestricting to allow v5 could be fine. If people need to constrain it, they can.

[jwoodrow]

I agree that the gem should release the version lock if it works with parallel_tests v5 (supposing ruby 3.2+ of course) users of the gems should know to deal with issues that relate to parallel_tests with a version lock on their end, no ?

[gap777]

I agree with @pboling and @jwoodrow ; can you release the pin and verify compatibility, without forcing the upgrade?

[pboling]

It does work with latest Ruby and latest parallel tests. Allowing, but not requiring, v5 should be fine.

See my branch for all the latest fixes, but note that I have stopped using it due to deep incompatibility with simplecov. It needs work, and I documented what that was in this issue tracker.

I would love to hand it off to someone else who has time and is invested in making this approach better. I was about to pull the trigger on a hard fork to turbo_tests2, but decided instead to just go back to vanilla parallel_tests.

#69