Add ruby 3.4 CI and gem base64 listed

[hmdros]

• Add an entry to CHANGELOG.md that links to this PR under the "main (unreleased)" heading.

Description:

This PR adds base64 as a listed gem when using Ruby 3.4, since it's not a default gem but a bundled gem in Ruby 3.4.
REF: https://docs.ruby-lang.org/en/3.4/NEWS_md.html

I will abide by the code of conduct.

[JuanVqz]

Hey @hmdros I was reviewing your PR and running some tests around it, I wonder if that might help us to have a smooth inclusion of Ruby 3.4.

I have some questions in general.

• Where is the best place to add the base64 dependency? gemspec vs Gemfile
• Is it fine just having base64 without especifying a version?
• why would we want to specify a version for the base64 if it was a built-in gem for < 3.4 versions, I think ruby will use that instead of the one included in the gemspec.
• What is better for clarity in CI? having the bundler constrains or not...

I hope someone else shows up to answer those questions.

If something in the test PR I opened tracks on you feel free to pick it up and close my PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.98%. Comparing base (8c0077a) to head (1147a2d).
⚠️ Report is 13 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #124      +/-   ##
==========================================
- Coverage   98.41%   93.98%   -4.44%     
==========================================
  Files          17       26       +9     
  Lines         315      515     +200     
==========================================
+ Hits          310      484     +174     
- Misses          5       31      +26     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[hmdros]

Hey @hmdros I was reviewing your PR and running some tests around it, I wonder if that might help us to have a smooth inclusion of Ruby 3.4.

I have some questions in general.

• Where is the best place to add the base64 dependency? gemspec vs Gemfile
• Is it fine just having base64 without especifying a version?
• why would we want to specify a version for the base64 if it was a built-in gem for < 3.4 versions, I think ruby will use that instead of the one included in the gemspec.
• What is better for clarity in CI? having the bundler constrains or not...

I hope someone else shows up to answer those questions.

If something in the test PR I opened tracks on you feel free to pick it up and close my PR.

Thanks for your eyes here. I had previously CI failing with bundler -v 2.4.6 and thought I needed all that constraints to get a green CI. Didn't even notice that Ruby 2.6 was compatible with bundler -v 2.4.22.
Also agree that .gemspec should be a better place to add the base64 since it will install it if it doesn't encounter it as it should in Ruby 3.4, taking out dependency of if statement.
Will ask you a re-review and ask one more person to check it.

[fbuys]

Where is the best place to add the base64 dependency? gemspec vs Gemfile

If you’re developing a gem, dependencies that are required for the gem to function (in production or when used by others) should go in the .gemspec file under spec.add_dependency.

Dependencies only used during development or testing (e.g. RSpec, RuboCop, Pry) should go in the Gemfile or as add_development_dependency in the gemspec.

So if your gem’s runtime code calls Base64 directly, it belongs in the gemspec.

In Ruby 3.4+, base64 has been extracted from the standard library into a separate gem. That means even if it used to be “always available,” it’s now a runtime dependency that must be declared if your gem uses it.

Is it fine just having base64 without specifying a version?

Yes, omitting the version is fine if your gem works with all released versions of base64.

Ruby will automatically install the latest compatible version. You only need to pin a version if you rely on behavior that changed between releases or if a specific version caused regressions.

I think it is fine in our case to let base64 get resolved during gem installation.

why would we want to specify a version for the base64 if it was a built-in gem for < 3.4 versions, I think ruby will use that instead of the one included in the gemspec.

Before Ruby 3.4, base64 was part of the standard library — no gem installation required.

From Ruby 3.4 onwards, it was extracted into a separate gem. That means:

For Ruby <3.4, require 'base64' just loads the built-in version.

For Ruby ≥3.4, Bundler will install the base64 gem listed in your gemspec.

You don’t need to manually manage which version Ruby picks — it’s handled automatically by Bundler and RubyGems.

You’d only specify a version if you want to enforce compatibility with a specific release of the gem (for example, base64 >= 0.1.1).

Your gemspec dependency ensures that anyone using your gem on Ruby 3.4+ has base64 available — without breaking Ruby 3.3 or older.

I don't see why we are including base64, because we never require it.

What is better for clarity in CI? having the bundler constrains or not...

Not sure what you mean by bundler constraints?

I understand that for standard or stdlib gems like base64, it’s usually unnecessary — you can rely on your Gemfile.lock to lock versions for CI.

[JuanVqz]

@hmdros
Adding the constraint because copilot suggested it in my PR (as a good practice), and the latest version of base64 supports from Ruby 2.4 to 3.4, meaning it does not hurt having it. Once you add this I'll approve it, thanks!

Suggested change

	spec.add_dependency "base64"
	spec.add_dependency "base64", "~> 0.3.0"

[JuanVqz]

@fbuys the constrains I was talking about are here, Henrique had to add them into CI because the bundler version was not compatible (I guess).

[hmdros]

I don't see why we are including base64, because we never require it.

It was being called when running tests and called in webmock gem version 3.10.0
I checked and they removed the dependency.
Also vcr gem would need an upgrade but we can't since in version 6.2.0 drops Ruby 2.6 support

[JuanVqz]

I don't see why we are including base64, because we never require it.

It was being called when running tests and called in webmock gem version 3.10.0 I checked and they removed the dependency. Also vcr gem would need an upgrade but we can't since in version 6.2.0 drops Ruby 2.6 support

well, webmock should be able to do whatever vcr is doing; maybe we can remove the vcr dependency and use only webmock.
could you at least try it? if that is too complex, we can create an issue to have somebody else contribute to it.

let me know if you are going to give it a shot, if not I can approve and merge

[JuanVqz]

Hey @hmdros thanks for adding support for Ruby 3.4! 🎖️

Also thanks to @fbuys for jumping in with valuable info; you are the 1️⃣