Drop support for old Rails versions < 4.2

[deivid-rodriguez]

Summary

What do you think about dropping support for old versions of Rails and Ruby that already reached their End of Life?

Details

Motivation and Context

• Make maintainance easier.
• Simplify and optimize CI.
• Encourage easier contributions that don't need to be compatible with an excessive range of versions.

How Has This Been Tested?

Through the current CI setup.

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue).
• New feature (non-breaking change which adds functionality).
• Breaking change (fix or feature that would cause existing functionality to not work as expected).

Checklist:

• I've added tests for my code.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.

[xtrasimplicity]

Personally, I'm not too keen on removing support for rails 4-4.2, as these versions are still heavily used and I don't believe the maintenance impact is really such an issue.

The really old ruby versions, however, I can see having a slight impact on future maintenance.

Let's wait and see what the core team think. :)

[deivid-rodriguez]

Yeah, let's wait and see :)

[luke-hill]

In my opinion dropping the testing of old items and whatnot is fine (the rails 4.2 argument aside)

However whilst we are not using ruby 2.3 (or higher), specific code, there is no need to restrict users. Furthermore, you'll see this in other OS software that I / others maintain. Selenium for example still allowed 2.0 because they didn't use any 2.1 / 2.2 specific code. Although for selenium4 they will be, hence dropping support of older rubies.

[deivid-rodriguez]

@luke-hill Yeah, I see what you mean, but if we accept that as a reason, it kind of becomes a vicious circle: we keep support for old rubies because we don't use newer ruby features, and we don't use newer ruby features because we still support old rubies. For example, a contributor might find interesting to use squiggly heredocs for her code, but refrain from doing it because of the current support matrix.

[deivid-rodriguez]

In my opinion, the mere fact that a library or language version no longer gets security fixes applied is reason enough for dropping support.

[luke-hill]

The 2nd point you made about not using new features isn't what I was getting at.

If cucumber hypothetically needed some new feature, then the old ruby/ies would be removed. There's no question over (I can't use method X because it doesn't exist in old ruby/ies), unless you wanted dual support (Something very few gems I know about do)

To use an example. curb actively does not have a minimum ruby requirement, but they only test from 2.0 onwards I believe.

[deivid-rodriguez]

Normally you don't need to use new features and can get away without them, it's just nice to be able to use them.

To use an example. curb actively does not have a minimum ruby requirement, but they only test from 2.0 onwards I believe.

Not sure what you mean, that's an example of what?

In any case, it makes sense to keep the ruby support matrix in sync with cucumber-core, so I'm dropping the changes about ruby versions! 👍

[deivid-rodriguez]

I removed the changes related to ruby versions. Now the branch name is a bit misleading, I can close this PR and reopen a new one with a better branch name if needed 😃.

[luke-hill]

Generally this seems fine. I'm not a huge rails user, but I believe 4.2 is still quite widely used. But other than that it seems good to me.

Only reason for not approving is I know others were debating about this.

[olleolleolle]

@deivid-rodriguez I edited the title of this PR, to increase visibility. I hope my wording reflects your intent.

[deivid-rodriguez]

Yes, although that brings another discussion to the table. I think the minimum rails version should also be limited via gemspec, but I understand from previous messages that some contributors might prefer to only stop testing but keep implicit support?

[koic]

I also thought that it would be better to leave Rails 4.2.
Rails 4.2 is in the stage of security release (So it is not an EOL) .
https://guides.rubyonrails.org/maintenance_policy.html#severe-security-issues

Recently Rails 4.2.11 has been released.
https://weblog.rubyonrails.org/2018/11/27/Rails-4-2-5-0-5-1-5-2-have-been-released/

[olleolleolle]

If this were changed to drop rails40, rails41 from the testing matrix, would you be in favor?

[deivid-rodriguez]

Sounds good, I'll readd 4.2 then!

[koic]

If this were changed to drop rails40, rails41 from the testing matrix, would you be in favor?

IMO, If there is no strong reason for the core team, I think that it is good to drop Rails 4.0 and Rails 4.1 from the testing matrix.

[deivid-rodriguez]

I ended up limiting the minimum rails version through the gemspec as well, so I edited the PR title accordingly.

[deivid-rodriguez]

This should be ready to go now, are you ok with limiting the minimum rails via gemspec?

[luke-hill]

Seems solid.

[luke-hill]

This might need a slight prod.

[deivid-rodriguez]

What do you mean? Do I need to change anything?

[deivid-rodriguez]

I'm doing some dependency rework anyways in #395, so I'm going to go ahead and merge this with @luke-hill's approval! :)