required_ruby_version should be mandatory

[marcandre]

Executive summary: required_ruby_version should be mandatory. It is currently not even in the "recommended" section.

Rendered text

Adapted from rubygems/rubygems#3515

[soulcutter]

I have many more concerns - I do think adoption should be encouraged, but I am unconvinced this will actually result in the intended benefit. It will be a mild annoyance to a lot of people and be circumventable with permissive boilerplate, which would likely result in the same landscape we have today.

[olivierlacan]

The fact that an improvement may be circumvented because it's a mild annoyance should never be a reason to hold back from making an improvement if the benefits outweigh the mild annoyance: they clearly do.

We now have a majority of Ruby versions in production which don't support numbered parameters. Any gem that uses numbered parameters and doesn't want to support Ruby < 2.7 could do that with required_ruby_version but may not from sheer lack of awareness in the community.

Unlike higher bounds on gem versions, a lower bound on Ruby versions is likely never to need updating which means there's a much lower chance of churn on the gem ecosystem. The spread of required_ruby_version would also allow the community to observe the actual decline of minimal Ruby versions in the ecosystem, which would be boon.

[soulcutter]

@olivierlacan said

The spread of required_ruby_version would also allow the community to observe the actual decline of minimal Ruby versions in the ecosystem, which would be boon.

I hadn't considered that angle - I like it.

As far as whether or not an improvement may be circumvented, I think it very much depends on actual behavior. I'd love to get some stats connected to this about current adoption to illustrate how much of a problem this is (I think we all suspect it's... significant!). I'm open to the idea I could be surprised by the numbers in any direction, though - I just don't know, and that's why it could make a stronger case.

I'm fairly cynical, so it may distort my cost/benefit here, but the hypothetical worst case of nobody adopting it (and instead circumventing it) would be a net loss for adding friction to the system that doesn't meet a threshold for adoption that would be useful. Not sure what that threshold is, but that's how I'm thinking about it - if the needle moves from 10% to 20% that's not enough to really have made this effective in my mind versus the tradeoff of breaking gem specifications. I pulled those numbers out of thin air, though, feel free to substitute with more-real numbers.

ANYWAY, don't let my cynicism stand in the way of progress - I hope it was taken constructively!

[simi]

I'd love to get some stats connected to this about current adoption to illustrate how much of a problem this is (I think we all suspect it's... significant!).

@soulcutter here you are http://ecosystem.rubytogether.org/.

[soulcutter]

That link is not helpful

[simi]

@soulcutter you can see distribution of Ruby versions across clients. You should be able to get info about "required_ruby_version" using public rubygems db dump.

[soulcutter]

You should be able to get info about "required_ruby_version" using public rubygems db dump.

Correct, I am suggesting that would be useful info here. I'm dropping out of this thread, though, I've said my piece.

[olleolleolle]

(💎 Thanks for adding RFCs, @marcandre. Here's a meta note, for scannability.)

RFC authors often link to the rendered Markdown document in the Description of the Pull Request:

[Rendered text](https://github.com/marcandre/rfcs/blob/master/text/0000_require_minimal_ruby_version.md)

Readable and nice:

Rendered text

[simi]

I tried to do a quick "analytics" in production dump (few days or month old) if anyone is curious about current numbers for required_ruby_version per gem for latest release.

TL;DR: 152325 out of 169658 gems doesn't set required_ruby_version at all (if my numbers are right).

data - https://gist.github.com/simi/c280428ab90ca35d470e61a2191ed101

PS: >= 0 is default when not set AFAIK (https://github.com/rubygems/rubygems/blob/cefa7c7222eb8bffee322233c06b2921ce2c9631/lib/rubygems/requirement.rb#L37)

[jacobat]

I'm not sure this is a good idea.

First up I can't recall having gems not supporting my Ruby version being a problem for me ever. It might be good to add some examples from your experience to the RFC detailing exactly why this is a problem.

Second, the basic premise is that gem authors are capable of determining the Ruby versions compatible with the gems they're producing. Thinking about this I think it will be very few gem authors that are able to correctly specify exactly which Ruby versions are supported, at least without a real investment of time. Unless you have a sufficiently thorough test suite as well as the infrastructure to run your tests against all versions of Ruby you have no way of specifying this correctly. Of course it's easy to say "I'm using numbered arguments, so Ruby 2.7 is minimum". But there are a lot of other cases where it's much harder to determine. For instance, which Ruby version introduced the &. safe navigation operator? Or Enumerable#lazy? And would the author even think about these things or would they just default to specifying "the Ruby version I'm currently using"?

[deivid-rodriguez]

Didn't have time to go through this yet, but to add more information to the thread in case no one mentioned it, the default bundle gem template includes this field by default since bundler 2.1.

[marcandre]

First up I can't recall having gems not supporting my Ruby version being a problem for me ever.

I'm glad this is your experience. Maybe you are using a modern version of Ruby all the time, in which case it is normal this would never happen to you. Do you maintain gems that support non super recent version of Ruby though? In any case, the fact that some users like you don't currently experience negative consequences of the fact that 90% of gems don't specify the minimum version of Ruby required is not a valid reason to not improve the situation for those of us that do.

It might be good to add some examples from your experience to the RFC detailing exactly why this is a problem.

My proposal already list at some other party who had the same issue.

A recent example is our test-suite breaking because we check a Rails 5.1 dummy project with Ruby 2.1. See rspec/rspec-rails#2319

I'm also updating a legacy Rails 3.2 + Ruby 1.9.3 project (🤷 ) to Rails 4+ / Ruby 2.2 (and more if I can). I had at least half a dozen such instances of gems failing to install because of the versions of Ruby.

Second, the basic premise is that gem authors are capable of determining the Ruby versions compatible with the gems they're producing

I don't share your view which I find condescending. Note that the author is definitely better at determining that than users of the gem, and that determination should ideally be done once (by the author) and not O(N) times (by some of its users).

Of course it's easy to say "I'm using numbered arguments, so Ruby 2.7 is minimum".

This would already be a better situation than not specifying anything. Better too strict a requirement than too lax. An overly strict requirement can be loosened and a patch release can be published. Nothing (currently) can fix an overly lax requirement.

[jacobat]

First up I can't recall having gems not supporting my Ruby version being a problem for me ever.

I'm glad this is your experience. Maybe you are using a modern version of Ruby all the time, in which case it is normal this would never happen to you. Do you maintain gems that support non super recent version of Ruby though? In any case, the fact that some users like you don't currently experience negative consequences of the fact that 90% of gems don't specify the minimum version of Ruby required is not a valid reason to not improve the situation for those of us that do.

There is however a point to be made that you have to consider the consequences of the proposal if the majority of people are not experiencing the problem you're having. To state that we should put a new requirement on all gem authors which will come with it's own set of downsides because a minority of people are having issues using certain gems is not necessarily reasonable. I'm not saying that it isn't, just that it might not be.

Surely it is a good thing to improve the situation. And I think submitting patches to gems helping with the specification is a good way to improve the situation. Putting a blanket requirement on everybody is not a good way to improve IMHO.

And for context: No I do not maintain any gems that support old versions of Ruby. The gems I maintain are all proprietary and have no need to support old Rubies.

It might be good to add some examples from your experience to the RFC detailing exactly why this is a problem.

My proposal already list at some other party who had the same issue.

A recent example is our test-suite breaking because we check a Rails 5.1 dummy project with Ruby 2.1. See rspec/rspec-rails#2319

I'm also updating a legacy Rails 3.2 + Ruby 1.9.3 project (🤷 ) to Rails 4+ / Ruby 2.2 (and more if I can). I had at least half a dozen such instances of gems failing to install because of the versions of Ruby.

Thank you, this makes it much easier for me to understand the issue.

Second, the basic premise is that gem authors are capable of determining the Ruby versions compatible with the gems they're producing

I don't share your view which I find condescending. Note that the author is definitely better at determining that than users of the gem, and that determination should ideally be done once (by the author) and not O(N) times (by some of its users).

You find it condescending to state that gem authors will have to make "a real investment of time" to determine the correct Ruby requirements for their gems? I'm not sure how that's condescending. I wouldn't know how to figure out what versions of Ruby any given piece of code is compatible with without spending a significant amount of time. Again, I can't think of any way to do this apart from running tests against all supported versions of Ruby, which in itself is time consuming. If you know of an easier way please do share.

I don't understand how you can argue that the gem "author is definitely better at determining that than users". Authors are not by definition more experienced or knowledgeable about Ruby than the users. I think the examples you present shows how authors might not always be better positioned to detect issues: You, the user, experience problems with a gem on the Ruby version you're using, that the authors did not realize was a problem before you told them.

We do agree, that it is more efficient if the author is able to do so once compared to every user having to figure this out on their own.

Of course it's easy to say "I'm using numbered arguments, so Ruby 2.7 is minimum".

This would already be a better situation than not specifying anything. Better too strict a requirement than too lax.

A too strict requirement will make it impossible for users of older versions of Ruby to use a gem. A too lax requirement does not make it impossible for users of older version of Ruby to use a gem, it does however introduce the extra hassle of figuring out which version they can use and pinning that in their Gemfile.

IMHO the second option is the better option as it does not exclude people from using code they could be using while the first option will.

An overly strict requirement can be loosened and a patch release can be published. Nothing (currently) can fix an overly lax requirement.

Regardless of making required_ruby_version mandatory or not there will be examples of overly lax requirements when people accidentally introduce code that is not compatible with the specified required_ruby_version in new versions of gems. So if there really is no way to deal with overly lax requirements today, enforcing a required_ruby_version won't fix the problem.

The example you mentioned appears to contradict the assertion though:

Now, the correct way of solving this problem is not to yank the gem, but to push a 7.6.1 or 7.8.0 which was simply the code from the last version of 7.4.x that supported 1.8.7 and therefore 1.8.7 users would pick that version up instead of 7.6.0, while existing Gemfile.lock users would be able to download 7.6.0.

[deivid-rodriguez]

TL;DR: 152325 out of 169658 gems doesn't set required_ruby_version at all (if my numbers are right).

data - https://gist.github.com/simi/c280428ab90ca35d470e61a2191ed101

PS: >= 0 is default when not set AFAIK (https://github.com/rubygems/rubygems/blob/cefa7c7222eb8bffee322233c06b2921ce2c9631/lib/rubygems/requirement.rb#L37)

Could we run the same kind of thing, but only against the most popular gems? Say, the 100 most downloaded or something like that.

My hunch is that the percentage of gems that do set the required_ruby_version field is much higher among these gems. The rationale is that most popular gems have probably dealt with user reports regarding ruby version breakage in the past, and that probably resulted in them adding the field to their gemspec files. I believe rspec-rails case was an exception here, because it had technically never dropped support for anything up until now, which I believe is very rare. But these are just guesses.

[marcandre]

Surely it is a good thing to improve the situation. And I think submitting patches to gems helping with the specification is a good way to improve the situation.

Let me repeat that once a gem is out with too lax a Ruby requirement, nothing can be done do fix that. I believe rspec-rails is thinking about releasing a 4.0.1 version with an install hook that detects older Ruby to instruct users to add a <4 gem requirement and then release a 4.0.2 version with a require_ruby_version.

You find it condescending to state that gem authors will have to make "a real investment of time" to determine the correct Ruby requirements for their gems? I'm not sure how that's condescending. I wouldn't know how to figure out what versions of Ruby any given piece of code is compatible with without spending a significant amount of time.

I meant that I find "very few gem authors that are able to correctly specify exactly which Ruby versions are supported" to be condescending. My gems test for different Ruby versions using a Travis and those versions are specified in the .travis.yml file. Setting this up typically takes me a few minutes.

Again, I can't think of any way to do this apart from running tests against all supported versions of Ruby, which in itself is time consuming. If you know of an easier way please do share.

I'm not sure I understand how testing against all supported of Ruby is time consuming; I typically will let those tests to be done on Travis and they are typically run in parallel so don't actually take anymore time.

A too strict requirement will make it impossible for users of older versions of Ruby to use a gem. A too lax requirement does not make it impossible for users of older version of Ruby to use a gem, it does however introduce the extra hassle of figuring out which version they can use and pinning that in their Gemfile.

IMHO the second option is the better option as it does not exclude people from using code they could be using while the first option will.

The first option can be resolved. The second option can not be resolved once for all future users. The first option is an active mistake. The second option, when no require_ruby_version was specified, is a passive mistake.

Regardless of making required_ruby_version mandatory or not there will be examples of overly lax requirements when people accidentally introduce code that is not compatible with the specified required_ruby_version in new versions of gems. So if there really is no way to deal with overly lax requirements today, enforcing a required_ruby_version won't fix the problem.

We completely agree it won't completely fix the problem. A way to retroactively tighten requirements on a published gem would. Until we can do that though, mandatory required_ruby_version will help with this shortcoming, even if it does not resolve it completely.

The example you mentioned appears to contradict the assertion though:

Now, the correct way of solving this problem is not to yank the gem, but to push a 7.6.1 or 7.8.0 which was simply the code from the last version of 7.4.x that supported 1.8.7 and therefore 1.8.7 users would pick that version up instead of 7.6.0, while existing Gemfile.lock users would be able to download 7.6.0.

That's a possibility, although it breaks semantic versioning. Take the example of rspec-rails, they could indeed publish a version 4.0.1 which would be a copy of the latests 3.x.x series, then republish a 4.0.2 as the 4.0.0 with the correct required_ruby_version. This would fix the requirements for most users, but could lead to a certain confusion regarding documentation as to what "v4" entails. They could alternatively "give up" of the v4 line and jump to 5.0.0 with the right required_ruby_version specified.

I still believe that publishing any gem today without a required_ruby_version is a bug (unless you actually support Ruby 1.8.7 😆 ) and we should do what we can to prevent that.

[marcandre]

I'm also updating a legacy Rails 3.2 + Ruby 1.9.3 project (🤷 ) to Rails 4+ / Ruby 2.2 (and more if I can). I had at least half a dozen such instances of gems failing to install because of the versions of Ruby.

I can't reproduce this anymore and it wasn't because of unspecified required_ruby_version, my mistake. Maybe that was due to an old version of Rubygems that I later updated.

[marcandre]

Let me summarize my position:

Publishing an updated gem today without specifying required_ruby_version is, in the vast majority of cases, an error.

By allowing gem authors to publish updates without any required_ruby_version we allow them to make these errors.

I will let the powers to be to find what is the best course of action. That consists probably on a selection of:

• required_ruby_version should be listed in the "recommended" section of the doc.
• a warning could be issued when pushing a gem without one. Could be a deprecation warning that this would be required in the future.
• required_ruby_version should be mandatory (but spec.required_ruby_version = :unknown or nil be acceptable)
• required_ruby_version should be mandatory

I have spent way too much time on what I thought would be a simple affair. I still can not comprehend how generating a default spec.required_ruby_version = '...' for bundle gem my_shiny_new_gem was such an easy affair while my proposal got so complicated with many non-constructive comments and irrelevant nit-picks. I'm afraid I have reached my frustration limit and I intend not to comment further.

[simi]

Do not gave up @marcandre this is actually good proposal, we just need to find out friendly way of introducing that.

I suggest to:

1. change bundle gem command to generate default required ruby version (the same actually when it is not specified at all) with TODO comment to change it. I think it is impossible to provide some other sane default here.

# TODO: select supported version
spec.required_ruby_version = '>= 0'

2. Move required_ruby_version to recommended section in guides.

3. During gem build we should warn about using required_ruby_version with >= 0 as not recommended. That would work when that attribute is not specified at all as well if I understand it well, since >= 0 is internally set when missing. We warn about similar problem when using some dependency constraints, I do not see problem add this warning as well.

[duckinator]

EDIT: I agree with @simi's response below. I think >= 0 is probably the safest option, and certainly the simplest.

Original comment

I'm not entirely sure of my position on this, but I do like @simi's suggestion of a warning instead of making it a hard requirement.

To add on to what @simi suggested:

1. If we have RubyGems expose a constant, such as RubyGems::RECOMMENDED_MINIMUM_RUBY_VERSION or similar for bundle gem to use, it avoids the problem of having to synchronize the number between the two projects.
2. I'd suggest >= 2.3.0, not >= 0. I explain my reasoning in the next paragraph.

According to https://stats.rubygems.org/, this would cover >90% of requests using Bundler and RubyGems. This could be generalized to be the fifth-newest release (as mentioned on the Ruby Maintenance Branches page), and be updated in future Bundler versions whenever is deemed appropriate. (The exact details of "whenever is deemed appropriate" can be determined later.)

[simi]

@duckinator I would like to keep the default gemspec safe. Specifying >= 2.3.0 as default will not make it safe since:

1. you will not get warning to check your used version
2. This value can be wrong (you can still use some of Ruby 2.5 specific feature, but leave 2.3 in gemspec). So we will end up with having gemspecs specified >= 2.3.0, but that would be wrong value. The goal of this is not to fill it in at any cost, but make gem maintainers to fill it with proper value. In my proposal, for new gems it will warn you during build time and you need to provide version manually. For current gems it will warn during build time as well and you need to provide value manually again.

🤔 I can imagine pre-filled value only with some kind of static analysis of the code deciding what's minimal version needed for syntax used, but the's really out of scope of rubygems IMHO.

[duckinator]

Coming back to this and re-reading the entire proposal + conversation, I'm in favor of the suggestion @simi made above. I'd also be open to revisiting making required_ruby_version mandatory in the future, but I believe it should be recommended for a while first to make the transition more friendly for end-users.

[simi]

Would it make sense to make required_ruby_version recommended, warn about default >= 0 value and also warn/inform when gem is built on newer version than specified in required_ruby_version to make final notification to maintainers to ensure value is still valid?

[marcandre]

warn/inform when gem is built on newer version than specified in required_ruby_version to make final notification to maintainers to ensure value is still valid

Please no. Not only is it not incorrect to release from a newer version of Ruby, it is probably the norm. I let my CI check conformity with older rubies, I never run them locally and my default Ruby is always the latest, so I would get warnings all the time. Let's not add a warning that will be incorrect most of the time for an action that is perfectly valid

[voxik]

I am against this proposal, especially because of the formulations such as: "If the author has not thought of that, this important concern will now be in focus.". There are far more important concerns such as license and reporting this to upstream, I have heard many times "submit PR with whatever you like". If this will be enforced, I am pretty sure somebody will submit there some value, but it won't say anything about the really required version.

That was one concern, but there will be authors, who will just try to limit their support matrix, therefore they will choose the Ruby version they currently use and won't bother with anything else. Again, this won't provide too much value IMO.

I understand this might be fine having just Ruby ecosystem in mind, but this kind of version limitations makes harder to integrate Ruby projects into Linux distributions. Please note that while Ruby 2.0.0 might be EOL upstream, but nonetheless, this version is still supported on RHEL 7. Similarly for Ruby 2.5, this will be supported on RHEL8 for ages. Therefore if anybody just handwavy adds required_ruby_version >= 2.6, because this is the upstream supported version, this does great disservice to everybody using such long term supported Linux distribution.

IOW there should be good reasons to add required_ruby_version, which should be given by technical constraints. But this proposal does not cover this, it just blindly mandates the value.

[voxik]

Just FTR, while not directly speaking about required_ruby_version, there is currently ~35 (from ~400) gems we needed to adjust gem requirements in Fedora.

[simi]

@voxik this is IMHO really specific need of Fedora (or similar software packaging) which is highly incompatible with other software package software by design. Fedora is just user, the same as any other gem user. If you need to keep gem supported for given version, you should contact gem author and find out if it is possible to help with maintaining older version. If you decided to support Ruby after EOL, you need to keep it maintained on your own.

You should actually try to fix the problem in the beginning. You can ask Ruby itself to provide longer stable releases, maybe some kind of LTS versions. There is Rails LTS project - https://railslts.com/. You can also provide help to related gems... But rejecting this RFC is just a bandaid for your problem.

[dentarg]

I agree with @simi, the problem of "technical incorrect" values for required_ruby_version can occur regardless of this RFC (and Fedora would need to deal with it (and already does for some)).

[voxik]

this is IMHO really specific need of Fedora (or similar software packaging) which is highly incompatible with other software package software by design.

Frankly, I don't understand where this hostility against Linux distribution comes from, because I can't see what is the base for this claim. On one hand you claims that "Fedora is just user", but OTOH you completely disregard the user feedback you are provided. So is Fedora/RHEL perspective valid and valuable or not? And yes, for better or worse as a Ruby maintainer on Fedora/RHEL, I represent the Ruby users on those platforms who don't come to provide their feedback here themselves.

But rejecting this RFC is just a bandaid for your problem.

Checking versions is always bandaid. I think we should agree on this. If this was about checking features, that would be more robust design. And that is actually the point. I see too many version check around, while there are better mechanisms in Ruby.

[voxik]

And just FTR, Vagrant is one of the prominent Ruby project which is locking Ruby version:

https://github.com/hashicorp/vagrant/blob/3d68e16f1b5d616f879d24f48dac2598acac0a38/vagrant.gemspec#L15

And we have to deal with it:

https://src.fedoraproject.org/rpms/vagrant/blob/61abdd780241ab2ac6aaa09597ece815564868bd/f/vagrant.spec#_141

Yes, they have their reasons, because their priority is VirtualBox support, while our priority is to have more recent version of Ruby. Nevertheless, I am quite sure that the support for VirtualBox could check the features instead of restricting versions (this is from my experience, but I might be wrong).

[simi]

Frankly, I don't understand where this hostility against Linux distribution comes from, because I can't see what is the base for this claim.

There is no hostility from my side. Paradoxically I'm actual Fedora user and I'm really enjoying the ecosystem. I'm just trying to explain (for longer time) what's wrong with Fedora repackaging of RubyGems since those are two different software managers with different goals and high level purposes.

On one hand you claims that "Fedora is just user", but OTOH you completely disregard the user feedback you are provided. So is Fedora/RHEL perspective valid and valuable or not?

Fedora itself (represented by you in here) is in my 👀 just user consuming RubyGems packages. But Fedora users itself are not users of RubyGems, but users of repackaged gems of Fedora. I do not disregard the user feedback, I'm just trying to explain this is not RubyGems problem at all you're trying to solve at RubyGems side.

I represent the Ruby users on those platforms who don't come to provide their feedback here themselves.

As mentioned before, I'm one of those users and I'm thankful for all the work.

Checking versions is always bandaid. I think we should agree on this. If this was about checking features, that would be more robust design. And that is actually the point. I see too many version check around, while there are better mechanisms in Ruby.

That's totally valid argument, but if I understand it well it is nothing we can solve right now in RubyGems. Feel free to open this issue at Ruby side to provide mechanism for feature checks and also for checking the code. That way during gem packaging it would be simple enough to check which Rubies are compatible. Or even we can check that at resolve time.

But that's sounds like utopia. Currently Ruby ecosystem is based on constraints maintained manually by maintainers for dependencies, RubyGems and Ruby itself. And the same benefit brought by dependencies constraints and dependency resolver (so you don't have to manually look up and test which version of dependency is compatible with the gem) is brought by required_ruby_version constraint. We heavily recommend to lock dependency constraints and I don't see any reason (or difference) why we shouldn't make it the same for required_ruby_version as well.

---

written at my Ruby workstation

[retro@retro  ~]❤ uname -a
Linux retro 5.16.9-100.fc34.x86_64 #1 SMP PREEMPT Fri Feb 11 17:28:33 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux