Long running 4.0 development branch

[fables-tales]

This will serve as the primary development branch (master) for RSpec Rails 4.0 until it is merged, and the 3.xx series is in maintenance mode.

Feel free to open pull requests against this branch if you'd like them to be included in 4.0

Drops support for rubies less than 2.3 and railses less than 4.2

Also updates the rubocop configuration to be dramatically more modern.

[fables-tales]

@JonRowe should we drop bundler 1.xx support here?

[JonRowe]

@samphippen Depends. Are you intending to support Rails 4.2 still? Rails 4.2 requires bundler 1.x

[joshRpowell]

Is this system spec generator a candidate for inclusion here? #1933

[JonRowe]

Its not a blocked for this @joshRpowell it could be targeted here if desired

[srbaker]

I've got a small build fix over here: https://github.com/srbaker/rspec-rails/commit/2aecf38e3d65ac185389ddc0bb3586670b5cf430

Looking into CI failures now. (Sorry, I don't know GitHub well enough to know how to do this correctly.)

[srbaker]

@samphippen the build failure (at least the one I'm getting) is related to this. rails/rails#34980

See line 1098 of the travis output. https://travis-ci.org/rspec/rspec-rails/jobs/484025072#L1098

[fables-tales]

@srbaker so we should move the RAILS_ENV= environment variable assignment to the prefix of the command?

[srbaker]

@samphippen Pretty sure that will work. I'm just back from FOSDEM with my annual FOSDEM cold, so I'll confirm and make a patch as soon as I can.

[fables-tales]

Hi Everyone,

This version of RSpec Rails will be released either shortly before, or some time after Rails 6 is released. At that point in time, support for serious security issues will be versions 6.0, 5.2, 5.1, and 5.0, dropping 4.2. When we started this branch, we had planned to support 4.2 as part of the RSpec Rails 4 release. This lead me to the question of what we should do about 4.2 support. According to our new versioning policy, we’re only going to support versions of Rails that are themselves supported for serious security patches. Against that, is the real world fact that there exist many people who are still on 4.2, and are greater than one year away from being upgraded off it.

As such I want to offer the following plan for discussion, but I think I’m going to follow this unless I hear serious concerns:

• This branch will keep a single 4.2 build (against the highest supported ruby version) green
• At 4.0 release time, 4.2 will be removed from the build matrix, but not the gem spec
• 4.2 will not be officially supported in RSpec Rails 4, and bugs against that version will not be fixed
• A warning will be issued at require time, if a user is using Rails 4.2, indicating to them that while the version is unlikely to be supported, bug fixes will not be issued against 4.2
• A warning will be added to the issue template indicating the lack of support for 4.2

Now, let’s talk about the practical effects of this: We’re not deleting any rails version specific code in this release, so it’s wildly unlikely that we’ll do anything that’ll break the 4.2 build. Running a single 4.2 build in this series is very cheap, so I’m not concerned about maintenance costs only while this branch exists. The future odds of us breaking some 4.2 specific code I would say are relatively low, at least in the initial days of adding rails 6 specific supports.

So, the end result here is that 4.2 is unsupported as of RSpec Rails 4, except that we know for a fact we’re not forcing users to migrate rails up until the next major (5), which is who knows how far off.

/cc @JonRowe @benoittgt

[benoittgt]

Hello @samphippen and thanks a lot for this plan that I approve.

Do you need help on last two dot points or somewhere else?

Cheers

[fables-tales]

@benoittgt if you could push a patch which deals with the questions that Jon asked, that’d be spectacular!

[benoittgt]

@samphippen Here we go #2081

I have also added #1933, #2077 and a fix for the CI with SQlite that is needed

[benoittgt]

The last CI build was not built after my force push. https://travis-ci.org/rspec/rspec-rails/requests

I rebased and push. I hope it is ok for you.

[benoittgt]

Should we start the release following #2067 template?

It is maybe different for a major release?

[benoittgt]

I looked at the failing CI. https://travis-ci.org/rspec/rspec-rails/jobs/598876421

We have this

NoMethodError: undefined method `name' for nil:NilClass

  /home/travis/.rvm/gems/jruby-head/gems/bundler-2.0.2/lib/bundler/resolver.rb:52:in `block in start'

From rubygems/bundler#6979 we should no longer have the issue if we use recent rubygems version. On the failing build we are installing old rubygems version. When we look into the CI log we have script/update_rubygems_and_install_bundler: line 8: is_ruby_23_plus: command not found.

It seems the recent merge removed this code : dd8f4ec

@JonRowe did you make something specific to have this result? I don't get it. 😂

master...4-0-dev#diff-f5ad4b13ba51e445039db0e799916596

[benoittgt]

Thanks @JonRowe 🙏
Are we good to release?

[JonRowe]

@benoittgt certainly getting ready to merge