RSpec Rails 6.0 Release Plan

[JonRowe]

@pirj @benoittgt we need to get some rspec-rails releases out, these are the steps we need to complete to do this:

• Merge / Cherry pick to 5-0-maintenance any outstanding 6.x patches we can
  • Support for Ruby 3.1 Add Ruby 3.1 for 5-0-maintenance #2564
• Release 5.0.3
• Create 5-1-maintenance without the Rails 7 patches.
• Merge / Cherry pick to 5-1-maintenance the final few tweaks for rails 6.1.
  • Support for Ruby 3.1 Setup 5-1-maintenance without Rails 7 but with Ruby 3.1 #2562
• Release 5.1.0
• Essential to merge to main
  • Support for Ruby 3.1 Add Ruby 3.1 (without Rails 7 support) to main #2563
  • Fix the type of handlers options passed to render #2521
  • Add Ruby 3.1 to CI and fix Rails 7 #2552
  • Sort out the mailer merges
  • Include ActiveSupport::Testing::TaggedLogging for Rails >= 7 (rebased) #2587
• Optionally
  • Release RSpec libs at 3.11
  • Merge to main Use RSpec.current_scope #2511 (see 3.11)
  • Merge to main Respect RSpec default_path for generators #2508
  • Merge to main Integration generator deprecation #2387
  • Merge Remove version-specific checks for unsupported Rails/Ruby #2614
• Merge Release prep for 6.0.0 #2567
• Release 6.0.0 supporting Rails 7, dropping Rails 5, minimum rspec version 3.11.

This is because major version changes are required for new rails versions for us under our release policy, but this means a bunch of branch wrangling, we could drop some of the changes for main in the name of expediency, thoughts?

[pirj]

we could drop some of the changes for main in the name of expediency

Sounds good.
I've restored the branch for #2546, those who want to have support for Rails 7 right now can use combo-have_enqueued_mail-fixes branch meanwhile.

[JonRowe]

I've restored the branch for #2546, those who want to have support for Rails 7 right now can use combo-have_enqueued_mail-fixes branch meanwhile.

Why? It's still merged in main. Only the new 5-1-maintenance skips it?

[pirj]

Because I've suggested using this branch 🙈 thinking that this commit will be taken out of main.

[JonRowe]

Please feel free to merge any rails 7 fixes to main as I intend to release this within a reasonable timeframe, if we were developing a longer term stable (like rspec 4) i'd revert but for rspec-rails its just as easy to pull the commits out of the stable 5.x series.

[pirj]

I'd prefer merging #2508 to main after releasing 5.1.x for simplicity.
Edited the description.

[pirj]

5-1-development is ready for 5.1.0 release, @JonRowe

[JonRowe]

I'm afraid its not @pirj, you merged my PR prematurely.

[JonRowe]

5.0.3 and 5.1.0 are released

[leboshi]

FYI, #2325 is moot now; 3 commits, the last of them 3ccd1f on 1/20/2022, made it obsolete.

[JonRowe]

I've released 6.0.0.rc1 with the changes so far in order to help those who need a release without a git dependency. Theres mostly the mailer behaviour changes to sort out before releasing a final version, and the tagged logging pr.

[pirj]

@JonRowe Speaking of sorting out the mailer merges, it appears to me that we didn't introduce any breaking changes, on the contrary, we've fixed a deficiency when with ActionMailer::MailDeliveryJob, users had to add args:.

Everyone seems happy so far with 6.0.0-rc1, and I have several theories for that:

1. It is not widespread enough with just 80K downloads compared to 2.5M downloads of 5.1.2. A counterargument is that it is specifically used by those early adopters who needed the fix, and the fix worked.

2. There are very, very few usages of mailer matchers in the wild:

$ cd ~/source/real-world-rspec
$ rg --hidden --no-ignore --files-with-matches 'have_enqueued_mail|enqueue_mail|have_enqueued_email|enqueue_email'
rspec-rails/lib/rspec/rails/matchers/have_enqueued_mail.rb
rspec-rails/lib/rspec/rails/matchers.rb
rspec-rails/spec/rspec/rails/matchers/have_enqueued_mail_spec.rb
rspec-rails/Changelog.md
rspec-rails/features/matchers/have_enqueued_mail_matcher.feature
chatwoot/spec/controllers/platform/api/v1/users_controller_spec.rb
gitlabhq/spec/services/users/approve_service_spec.rb
gitlabhq/spec/services/notification_service_spec.rb
gitlabhq/spec/controllers/admin/users_controller_spec.rb
gitlabhq/spec/controllers/registrations_controller_spec.rb
gitlabhq/spec/support/helpers/notification_helpers.rb
gitlabhq/spec/requests/api/users_spec.rb
gitlabhq/spec/models/user_spec.rb

3. The fix worked for all combinations of Rails versions and delivery job class.

Basing on this, I suggest considering this item complete.

[jrochkind]

Hi, 6.0.0.rc1 has been out for 6 months now; is there any chance of a 6.0.0 non-rc final release soon? Anything anyone else can do to help? I would love to have a non-pre-release in which Rails 7 (out for 9 months) is supported; pre-releases like rc1 are handled differently by bundler/rubygems in some ways, which makes some tooling more confusing.

[JonRowe]

I think it makes sense to move on and release 6.0.0 as it is, we can address any resulting breaking changes in 7.0.0