[ruby-core:75286] [Ruby trunk Feature#12328] Show warnings about vulnerable and no longer supported Ruby versions.

Issue #12328 has been updated by Cezary Baginski.


I think this can be closed because:

1. JSON file can be created on ruby-lang.org and cached on other sites if necessary (I'll propose a format on https://github.com/ruby/www.ruby-lang.org)
2. Tools like rbenv, RVM, RubyGems and Bundler can use that file for showing warnings (Once format is agreed on, actual functionality can be suggested)
3. No changes in Ruby core are needed.

My guess is that RubyGems team will be least likely to accept such functionality.

Thank you for your time and feedback!

----------------------------------------
Feature #12328: Show warnings about vulnerable and no longer supported Ruby versions.
https://bugs.ruby-lang.org/issues/12328#change-58415

* Author: Cezary Baginski
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
## Problem

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

## Impact

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).

## Opportunity

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

## Suggestion

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

## Implementation

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).

## Alternatives

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 ruby-lang.org are extremely helpful, but sadly not read or tracked often enough by users and developers.


## Examples

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 ruby-lang.org).
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.


## Obstacles

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.


## References:

My draft/rant about how backward-compatibility hurts the community: https://gist.github.com/e2/ac32569852cbd31f7da637500174d907 (feedback and improvements are most welcome, even if non-technical!)



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>