Remove Ruby version constraint from the gemspec

[Marahin]

Hello,

we would love to use this gem to validate JSON payloads on-failure in our gem, jsonapi_parameters. This gem provides a simple way to consume JSON:API compliant inputs in Ruby, with Rails support included. You can read more about the standard here: https://jsonapi.org

Sadly, we are facing an issue where choosing json_schemer as the validation engine would mean that we would have to give up support for Ruby 2.4. While we are aware that this Ruby version has reached its EOL, we would rather not limit our users to specific Ruby versions unless it is required by the gem's logic.

Because of that we are currently seeing three scenarios:

• either exporting the validation as a plug-in (so the validation part would be excluded out of JsonApi::Parameters gem and instead be provided as a complementary gem),
• leave it as it is in the current state (PR link: [OS-17] JSON Schema validation visualitypl/jsonapi_parameters#45), thus give up for Ruby versions below 2.5.0,

and, the third scenario is: reaching out and asking whether its possible (and if not - what is the reason for this decision) to remove the constraint in json_schemer that enforces Ruby versions above 2.4.0. This is the path that we decided to choose first.

Commit link: 8cbd5cc#diff-6f69d521c8f547072ea493be84d7a52eL23-R23

[ahx]

IMHO with Ruby 3 just a few months to go, let’s nudge people towards using newer Ruby versions. 🚀

[Marahin]

IMHO with Ruby 3 just a few months to go, let’s nudge people towards using newer Ruby versions.

Why? Why forcing people to update their well-working scripts, gems, programs would be the way to go?
Ruby is an open-minded community, and while Ruby 3 is great, I think forcing anybody to upgrade their Ruby version solely because there's a newer one is a harmful approach.

Ruby version requirement should be dictated by the need of the language functionalities, as bundler.io suggests:

Like gems, developers can setup a dependency on Ruby. This makes your app fail faster in case you depend on specific features in a Ruby VM. (...)

So, in my understanding, unless json_schemer specifically needs features that are not present in Ruby 2.4, it shouldn't be specified as a dependency.

New applications should indeed be written in the highest Ruby versions possible, but please allow users that already have their use-cases covered to have their application still working without having to upgrade everything just so they can validate their JSON inputs.

// EDIT: added linkage and quotation to bundler.io

[ahx]

@Marahin Alright. Sounds plausible.

[davishmcclurg]

we would love to use this gem to validate JSON payloads on-failure in our gem, jsonapi_parameters.

Sounds great!

and, the third scenario is: reaching out and asking whether its possible (and if not - what is the reason for this decision) to remove the constraint in json_schemer that enforces Ruby versions above 2.4.0. This is the path that we decided to choose first.

I originally enforced Ruby 2.5 because 2.4 is EOL and I'd like to use some of the features in 2.5. Would it work for you to pin your dependency on an older version of the gem? I believe 0.2.11 works on Ruby 2.4. In fact, bundler should pick up that version when running on 2.4.

[Marahin]

@davishmcclurg indeed we could pin down to the version before the Ruby 2.5 dependency was introduced, but this way we are giving up on the new features, fixes and changes in your library, such as more precise errors: #1

So while this would indeed allow us to include and use json_schemer, it:

• creates another issue (what about new features? We are locking ourselves to one specific version),
• already by the time its introduced will be outdated

I'd like to use some of the features in 2.5

This is a super valid point, but are there any features that json_schemer is making use of right now? If yes, then this indeed discards our request and is a great argument behind setting this dependency up.

[davishmcclurg]

This is a super valid point, but are there any features that json_schemer is making use of right now?

I think you're right that there aren't any. I was thinking of some things I changed when I dropped 2.3.

but this way we are giving up on the new features, fixes and changes in your library, such as more precise errors: #1

That's true. I'm open to supporting 2.4 again since it shouldn't require any other changes. How long do you plan to support it? I don't have a good sense for people's expectations on these types of things.

Please open a PR with the changes, if you can.

[davishmcclurg]

Merged 2.4 support and released in 0.2.14.