Add deprecation warnings for features to be removed/changed in RSpec 4

[pirj]

A few things are a bit off, e.g.:

• no deprecation for multi-condition filtering usages 🤷
• no specs for :if/:unless deprecation usages
• had to flip the unless condition in snippet_extractor_spec.rb to skip it on Ruby 1.8 builds. Puzzled to understand how :unless => RSpec::Support::Ruby.jruby? && !RUBY_VERSION.start_with?('1.8.') was working (example failure)
• should we add deprecation warnings when running on rbx/ree/Ruby < 2.3?

This is purposed to be released as version 3.99.
Sibling PRs:

• Add deprecation warnings for features to be removed/changed in RSpec 4 rspec-mocks#1418
• Add deprecation warnings for features to be removed/changed in RSpec 4 rspec-expectations#1301

Release strategy: #2880 (comment)
RSpec 4 plan: https://github.com/rspec/rspec/issues/61
Changes: https://github.com/rspec/rspec-core/blob/4-0-dev/Changelog.md#development

TODO

• merge this PR, then rspec-expectations PR, then rspec-mocks PR
• revert this spec/spec_helper.rb change

[pirj]

@JonRowe Am I doing the right thing?

[JonRowe]

@pirj yep, thats the exactly the kind of thing we'll want in a final 3.x release.

We'll follow the 2.x strategy of:

• Release a 3.10 patch of any final bug fixes
• Release a final minor version containing any final enchancements
• Release 3.99 containing these deprecations
• Release 4.x

It's sufficient to keep these as a PR until we get to releasing 3.99, the first two steps are just release management as usual

[pirj]

Green!

I have seen features/command_line/init.feature:25, and features/command_line/bisect.feature (on JRuby) failing intermittently on CI. Might be flaky. Couldn't reproduce locally.

[benoittgt]

Thanks @pirj for this PR. 🙌🏻

should we add deprecation warnings when running on rbx/ree/Ruby < 2.3?

It means people will always have the deprecations when they use the last version chosen by bundler for their Ruby version?

[benoittgt]

@pirj are we good to merge it?

Sorry I scrolled back and saw

It's sufficient to keep these as a PR until we get to releasing 3.99, the first two steps are just release management as usual

[pirj]

This needs to be reverted when all three are merged.