[gemspec] raise upper limit on Bundler version to include 2.x.x

[rye]

Resolves #14016. 🔑

Checklist

• I've run bundle exec rspec from the root directory to see all new and existing tests pass
• I've followed the fastlane code style and run bundle exec rubocop -a to ensure the code style is valid
• I've read the Contribution Guidelines
• I've updated the documentation if necessary.

Motivation and Context

Bundler 2.0 was recently released, and those users who want to upgrade cannot do so until this gem removes its requirement on Bundler being less than 2.0. Moreover, users who are unable to satisfy the RubyGems ≥ 2.5.0 or Ruby ≥ 2.3 requirement imposed by Bundler 2.0 will not be forced to upgrade, I'm pretty sure. This PR just loosens the requirement. I thought about completely removing the upper bound, but decided not to.

Resolves #14016.

Description

This PR is a one-liner change to the Gemspec.

[KrauseFx]

I'm not super up to date, but I read somewhere bundler 3.0 doesn't work with the pre-installed Ruby of macOS. However from what I understand, this should still work for previous setups, right?

[rye]

This PR doesn't allow bundler 3.0 (which I don't think exists) to be used—2.0, however did introduce a strict requirement of ≥ 2.3.0 which will prevent the update on older macOS installs.

On macOS Mojave, I have

$ /usr/bin/ruby -v
ruby 2.3.7p456 (2018-03-28 revision 63024) [universal.x86_64-darwin18]

I'll note that the requirement imposed by Bundler on v2.0.1 is:

  if s.version >= Gem::Version.new("2.a".dup)
    s.required_ruby_version     = ">= 2.3.0"
    s.required_rubygems_version = ">= 2.5.0"
  else
    s.required_ruby_version     = ">= 1.8.7"
    s.required_rubygems_version = ">= 1.3.6"
  end

[rye]

The test failure I'm getting is:

expected Exception with "Invalid password passed via 'MATCH_PASSWORD'" but nothing was raised

But I am failing to see how this results from this change. I'll note that the test in question is setting ENV['MATCH_PASSWORD'] to "invalid", then expecting Match::Encryption::OpenSSL#decrypt_files to throw an error, which it only does if MATCH_PASSWORD is present in ENV… but that doesn't seem to be happening. I'd expect that to happen on multiple platforms. Am I missing something?

[janpio]

That's our one and only flaky test. I restarted the tests, should be fine in a minute.

[joshdholtz]

@rye Did 3.0 get pulled from RubyGems? 🤔 I'm not seeing it anywhere to be able to test this again system versions of Ruby and other installs of Ruby

[rye]

I'm pretty sure 3.0 never existed, since 2.0 was just released. This version operator just ensures that 3.0 never gets used if it does get uploaded, at least not until the gemspec is updated.

This is similar to how it was before, with bundler 1.0 being the old release and 2.0 being the upper limit.

[joshdholtz]

Oh man, I read this way to early in the morning without having enough coffee 😝 Let's ignore my comment and let me actually test this now

[joshdholtz]

This looks like it should be good 👍 This did work on my system version of Ruby (which is 2.3 and supported by bundler 2.0), worked on Ruby 2.2 (which doesn't support bundler 2.0), and my non-sytem Ruby of 2.3.7

[rye]

Sweet, thanks!

[fastlane-bot]

Hey @rye 👋

Thank you for your contribution to fastlane and congrats on getting this pull request merged 🎉
The code change now lives in the master branch, however it wasn't released to RubyGems yet.
We usually ship about once a week, and your PR will be included in the next one.

Please let us know if this change requires an immediate release by adding a comment here 👍
We'll notify you once we shipped a new release with your changes 🚀

[fastlane-bot]

Congratulations! 🎉 This was released as part of fastlane 2.113.0 🚀