Feature #12328


Show warnings about vulnerable and no longer supported Ruby versions.

Added by Cezary (Cezary Baginski) about 6 years ago. Updated about 6 years ago.

Third Party's Issue
Target version:



Users are often still using unsupported Ruby versions and developers and unknowingly supporting them.


Developers and maintainers are often "forced" to work extremely hard and support outdated Rubies in fear of backlash from the community. Also, it may take years until projects can comfortably adopt new Ruby features (e.g. Ruby 2.3 features).


Ruby now has "somewhat" SemVer-compatible versioning. This may help promote newer Ruby features without users being scared of migration headaches.


The last release of every unsupported Ruby should show a warning that upgrading Ruby is highly recommended.


This could be turned off depending on the warning level. End-users don't really need to see the warning during runtime. (It's more important for developers and maintainers to know first, and adding extra output by default would break Ruby API).


a) The packaging (OS, distribution, RVM, rbenv, Ruby build system) could show the warning upon installation or building. But since this is usually automated, few developers and users would get a chance to see the warning.
b) News updates on are extremely helpful, but sadly not read or tracked often enough by users and developers.


Example of this working in practice (for a user):

  1. User installs latest Ruby 1.8.7
  2. Ruby is in verbose mode or the warning level is set.
  3. User runs their application.
  4. User sees a warning that Ruby 1.8.7 is no longer supported and that migrating to Ruby 2.2 is recommended. (With possible link to post on
  5. User can upgrade to a newer Ruby or turn off warnings

Example of this working in practice (for a developer/maintainer):

  1. Developer uses tool to install Ruby during development/testing
  2. Tool installs latest Ruby at given version (e.g. latest patch-level of Ruby 1.9.3).
  3. Developer has ruby warnings enabled.
  4. Developer sees the warning about Ruby no longer supported (EOL).
  5. Developer updates codebase (removing old code, using newer language features) and documentation.
  6. Developer releases new version of their library which drops support for Ruby 1.9.3.
  7. User cannot update library until they upgrade their version of Ruby to one supported by library.
  8. User and Developer can discuss backporting options to ease migration.
  9. Either user upgrades to newer Ruby (so Developer has more time and fun to work on new features), or Developer gets appreciated for hard work to support outdated Ruby.


Some software maintainers are very disturbed when their builds/tests for outdated Rubies fail. Even if the reason is a good one and doesn't affect end-users. I don't know how to educate and encourage them in a polite and effective way.


My draft/rant about how backward-compatibility hurts the community: (feedback and improvements are most welcome, even if non-technical!)


Also available in: Atom PDF