Test over multiple ActiveSupport versions (with Appraisal)

[D-system]

Test ActiveSupport from 5.2 to 7.0 over ruby version 3.0 to 3.3.
It ensure that all versions are care of.

The matrix of tests is:
ActiveSupport 5.2: Ruby 3.0, 3.1, 3.2 and 3.3
ActiveSupport 6.0: Ruby 3.0, 3.1, 3.2 and 3.3
ActiveSupport 6.1: Ruby 3.0, 3.1, 3.2 and 3.3
ActiveSupport 7.0: Ruby 3.0, 3.1, 3.2 and 3.3

With the current limitation of ActiveSupport 7.0 max (from #279), when ActiveSupport 7.1 is supported we will have tests for 7.0 and below.

[D-system]

One of the dependency does not support Ruby 3+

There is a clear trade off:

• test over all ActiveSupport versions
• test over all Ruby versions
• force an old library version (and test all ActiveSupport and Ruby versions)

[D-system]

Other libraries are incompatible

[D-system]

At the end, I went to add more tests (not changing the current tests) and limit to Ruby 3.0+ due to too many incompatibilities with dependencies.

With this addition, we will have insurance that old versions are working once ActiveSupport 7.1 is added.

[D-system]

@Floppy I know the project was not using Appraisal and that add one more thing to think and know. I would be happy to help on spreading the knowledge even it is the first for myself too to use Appraisal.

If there is a need to a maintainer to maintain the code (no feature implementation), I would be happy to help. I would like to update the code to comply to StandardRb (remove the exceptions) and rely on the CSV gem version instead of the Ruby version (with the current PR that test against multiple Ruby version, it is safer to do that change).

[Floppy]

Sorry for the delay! This is super cool work, thank you. I've not used Appraisal before, but testing across multiple gem dependency versions is fantastic, so I'm happy for it to be added. Only question is, do we need to include the lockfiles in the repo, or should they (can they) be .gitignored?

[D-system]

Good question.
Let me spy on other gems 💎 to see what’s the consensus.
It was one of my concerns when making the commit.
I’ll probably add it to the ignore file as it is the behavior of the current test and gemspec.

[Floppy]

I think unless it's important for Appraisal to work properly, we should probably leave them out. 👍🏻

[D-system]

I looked at the reverse dependency https://rubygems.org/gems/appraisal/reverse_dependencies.

Commited:

• https://github.com/jwt/ruby-jwt/tree/main/gemfiles
• https://github.com/awesome-print/awesome_print/tree/master/gemfiles
• https://github.com/thoughtbot/factory_bot/tree/main/gemfiles
• https://github.com/sj26/rspec_junit_formatter/tree/main/gemfiles
• https://github.com/redis-store/redis-store/tree/master/gemfiles
• https://github.com/rack/rack-attack/tree/main/gemfiles
• https://github.com/paper-trail-gem/paper_trail/tree/master/gemfiles
• https://github.com/redis-store/redis-activesupport/tree/master/gemfiles
• https://github.com/thoughtbot/paperclip/tree/main/gemfiles
• https://github.com/NoRedInk/rspec-retry/tree/master/gemfiles
• https://github.com/winebarrel/faraday_middleware-aws-sigv4/tree/master/gemfiles
• https://github.com/thoughtbot/factory_bot/tree/main/gemfiles
• https://github.com/doorkeeper-gem/doorkeeper/tree/main/gemfiles
• https://github.com/aasm/aasm/tree/master/gemfiles
• https://github.com/CanCanCommunity/cancancan/tree/develop/gemfiles

Not commited:

• https://github.com/pry/pry-rails (no commit in the last 6 years)

It seems that most people are committing their gemfiles. I was leaning more to your side (not committing the gemfiles) yesterday but now after my research, I wonder. It is a political decision, there is no bad decision. With this research, I would like you @Floppy to confirm you want to let them out.