From: cezary.baginski@... Date: 2016-04-30T03:56:36+00:00 Subject: [ruby-core:75259] [Ruby trunk Feature#12328] Show warnings about vulnerable and no longer supported Ruby versions. Issue #12328 has been updated by Cezary Baginski. Migrating from Ruby 1.9.3 to Ruby 2.2 is trivial. But, people still remember that moving from Ruby 1.8.7 to 1.9.3 was difficult and risky. Ruby is used for so many important projects nowadays. People should be educated to upgrade Ruby more often. When people don't learn to upgrade, library maintainers get angry at other developers for using newer features. Also, many people mistakenly think that "security patches only" means "supported". So even a warning just for "spreading news" among developers is a big improvement. Would expiry dates make sense? E.g. Ruby 2.0.0-p648 (December 16th 2015) could have a "hidden" warning that would have become active after February 24th 2016. So in January 2016 - no warning. After February 2016 warning is always shown. Is this a good idea? Or should Ruby output be 100% unaffected by system date? ---------------------------------------- Feature #12328: Show warnings about vulnerable and no longer supported Ruby versions. https://bugs.ruby-lang.org/issues/12328#change-58390 * 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: