task: Remove support for ruby 2.4 and rails 4.2

[KapilSachdev]

• Remove obsolete rails version helpers for rails < 5
• Update all gem versions
• Disable Naming/VariableNumber Cop
• Use bionic distribution for CI

[KapilSachdev]

Travis CI builds have become very slow and are delayed as well due to recent changes in pricing structure which will ultimately lead to a credit based system for OSS as well.
@mcmire What do you think about switching to some other build platforms like buildkite offers unlimited as of now

[mcmire]

@KapilSachdev Ah, I didn't know about those changes. That's too bad.

We use Buildkite at my company, so I'm at least roughly familiar with it. I'm not 100% sure on how it was set up, but I know it's worked really well for us and is super customizable and fairly easy to set up. The only part I'm not sure about is how to emulate Travis's matrix, although I'm sure someone's written a blog post about it. But yeah... based on what people are saying in the Travis Forums it sounds like this is something we would need to do before the end of the year. :(

[KapilSachdev]

Yes, we will need to do that soon.
I will try Buildkite with my fork and update the findings here.

[KapilSachdev]

Before starting on buildkite, I gave github actions a try.
It is working fine with spec:unit but spec:acceptance are failing.

[vsppedro]

Hi, @KapilSachdev and @mcmire, I found this Drop legacy callback matchers under Rails 5 commit and I'm just sharing with you because I think we need to do that after dropping the support for 4.2 and before creating a major release.

It's just to remind us. Maybe an issue should be a better way to keep this registered. 😄

I will create one later, if you think the same way, of course.

EDIT: Or maybe this action needs to be done at the same time that we drop the support for 4.2. What do you think?

[mcmire]

Yes, going off of what @vsppedro is saying, if we are ready to work on 5.0.0 then that's totally fine to upgrade to Rails 6.1 at the same time as removing Rails 4.2 etc. My understanding however was that we were releasing a minor version next, is that true? In any case it might be more useful to split this into two PRs — one that adds Rails 6.1, another that removes 4.2. That way if we want to add Rails 6.1 now we can do that without having to remove 4.2 yet.

[KapilSachdev]

if we are ready to work on 5.0.0 then that's totally fine to upgrade to Rails 6.1 at the same time as removing Rails 4.2 etc

Yes, The PR was created focusing the next major release i.e. 5.0, which would change the minimum ruby and rails version support to 2.5 and 5.0 respectively.
I think we are ready. Is there any roadmap you have in mind for 5.0 @mcmire .

My understanding however was that we were releasing a minor version next, is that true?

If your understanding arises due to the 4.5.0 milestone, I just created it thinking the same.
@mcmire What do you think about skipping a minor one and making a major release?

In any case it might be more useful to split this into two PRs — one that adds Rails 6.1, another that removes 4.2

Sounds good. Will split it into two.

That way if we want to add Rails 6.1 now we can do that without having to remove 4.2 yet.

This 6.1 is a release candidate, and i'm not sure about the stable release timeline. So I think adding it with shoulda-matchers ~4 might delay ~5.

[mcmire]

@KapilSachdev Okay, good. I figured this was for 5.0.0 but I wasn't sure.

Speaking of 5.0.0, I just wrote up my thoughts about it including possible backward-incompatible changes we could make, so I'd be curious to hear your thoughts here: #1380

So, depending on which direction we are going and how much we want to include in 5.0.0, I think it may be useful to release a minor version next, that way we have a chance to deprecate things that we are going to remove later. I know that we are still probably going to get feedback from people after 5.0.0 who don't pay attention to the changelog 😆 , but at least it gives us a way to cover ourselves a bit and point them to a deprecation release.

[KapilSachdev]

I figured this was for 5.0.0 but I wasn't sure.

My bad that I didn't added any info to the draft about it being a part of 5.0.
I was into just testing the changes, though i found out later that travis ci is too slow to help.

I think it may be useful to release a minor version next

Yes, definitely. I totally forgot about the discussion of creating a deprecation cycle.

[vsppedro]

Hello, @KapilSachdev, I hope you are well. Do you still intend to work on this PR?

[KapilSachdev]

Hello @vsppedro,
Yes, I will work on it and try to complete it soon.

[vsppedro]

Hi, @KapilSachdev, if you update this with master the problem with Travis will be solved thanks to this PR: #1397.

You will still need to update the file responsible file for the ci workflow on the GithubActions. I think it's only necessary to remove the rails_4_2 appraisal and all the content of the matrix.exclude, but maybe I'm wrong.

I hope that helps!

[vsppedro]

Hello, @KapilSachdev, I hope you are well.

This has been covered by another PR.

Thanks!