Issue #12328 has been updated by Cezary Baginski.


**TL;DR - I'm listing real-life situations such warnings would address. Mostly about how people behave and what they expect. Just to demonstrate how important and useful such warnings could be.**


Jeremy Evans wrote:

> I am against ruby emitting warnings just because it thinks there may be a newer ruby version available.

So it's not about warning that Ruby 2.2.4 may be outdated, but that 2.1 will never get another bug fix (except for security).

A warning earlier is better than any "breakage" later. I agree warnings can be annoying. Then again, either people want important warnings (and this one important), or they can turn them off anyway with RUBY_OPT.

> the solution is not to modify the interpreter, but to stand your ground and tell the users (...) to fork the library.

I agree about standing ground. It just is a huge emotional and time commitment to explain to every angry person one at a time. I probably just have to find better ways of explaining things.

> Likewise, (...) you are free to fork the library and update it so that it only works on recent ruby releases.

That's true. I actually wish I'd done that earlier in some cases.

> IMO, dropping support for previous ruby releases is just a cost-benefit calculation.

I agree. It's that the users complaining aren't usually making that calculation rationally. They don't assess the actual costs.

People with genuine needs ask for backports. (Which I don't mind). But they don't mindlessly upgrade every library expecting their Ruby to be supported, either. Upgrading anything is actually very dangerous in such situations.

Use cases for warnings:

1. Library maintainers with bad assumptions like "Ruby < 2.2 is still officially supported" or "Ruby doesn't follow SemVer" or "Ruby 2.2 is only 'recommended'" or "security fixes mean it's still supported" or "a Ruby version is part of a gem's API", etc. A Ruby warning helps explain that a broken Ci build is just a missing long-overdue Ruby upgrade. I'm happy to support urgent bugfixes backported. I understand business needs. And people with those needs are usually very reasonable anyway.

2. Users using vulnerable versions of Ruby who don't even know their version is vulnerable. To them, it's not just about new features or benefits - they simply get angry too if even their ancient Ruby 1.9.3 "no longer works". So what I don't have is some "official" statement explaining: "Ruby < 2.2 is not supported. Security patches are provided, but only as a last-resort measure. This means it is ok for developers to drop support for Ruby < 2.2, unless they have clients who's businesses need access to earlier versions while migrating. Migration should be straight-forward in most cases." It isn't like e.g. support for Ruby 1.9.3 happened suddenly yesterday.

3. The biggest danger is e.g. people building services with outdated+vulnerable Ruby versions from older virtual machine images/containers. I think this is more important than any "developer inconvenience" when working with already outdated Rubies. IMHO sticking to only supported Ruby versions actually shows professionalism in the Ruby community, even if it's "just" a warning.

3. Urgency. A warning (or deprecation) can be dismissed or turned off without taking any other action. Meanwhile, a sudden bug or misscommunicated version dependency causes a lot of stress and unplanned work. If I implement that as part of my library, every "user affected" is an hour-long argument. Their reasoning is: "if Ruby isn't showing a warning, the library developer is just making things up and causing unnecessary problems".

4. Bugs in Ruby are the hardest to debug. They're just very time consuming if they occur. It's always the library that's suspect first, not an outdated Ruby version. So by staying up to date, professionals can avoid many hours wasted tracing "already-fixed-bugs" in their outdated Rubies.

5. "Complaint chain". Maintainers don't like users complaining so they prefer "everything to be supported". Same with developers - they don't like maintainers complaining. With a warning in Ruby, there's no "surprise". This means everyone ends up using 1.8.7 until there's no other option but upgrading. (So it can take many years until developers can start using Ruby 2.3-only features without reimplmenting them also in "1.8.7-compatible" code).

6. Understanding versioning and dependencies takes advanced skills. Most users don't have those. (And it's why I don't blame those "angry" maintainers). It's more practical to show a warning than to expect developers to accurately declare versions without a single mistake. (It's very hard to test and there are no good tools to help, either). Upgrading Ruby simply helps solve those issues, because there's only "one version of Ruby supported at a time".

7. The whole idea of supporting "many interpreter versions" with one codebase is something exotic. E.g. you don't expect all unmodified Python 2.x sources to work on Python 3.x. Even today, you can see most projects "confused" about how to treat the existence of multiple Rubies: 1.9.3, 2.0, 2.1, 2.2, 2.3. That's already "5 versions" of Ruby to support. Some projects still insist on supporting 1.8.7. In a library codebase that looks ok. But to test it all, you need a build matrix 5^^X (X = factors to test on a single version). And that's not even counting patch-level versions of dependencies.

8. Having no more than "two official Rubies" helps everyone. And it's not "official" if "just" a library owner like me says so. It isn't "ok" to use Ruby < 2.2. It's a potentially dangerous business situation already. It's like driving a broken car. If life is tough, there may be no other choice. But if you don't know you're driving a broken car, a warning gives people a reason to upgrade before they complain about accidents they'll have later on.

9. Users rarely know about the benefits and gains. If they did, they'd upgrade sooner. (And they'red be less artificial demand for "backward-compatibility").

Changing the interpreter makes things easier to communicate. The earlier and more "official", the better.

So I believe having warnings like these would be an enourmous benefit to communicate good practices and understanding in the community.

(Which would allow more productive time spent improving and promoting Ruby).


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

* 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:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>