From: merch-redmine@... Date: 2016-04-30T04:28:28+00:00 Subject: [ruby-core:75261] [Ruby trunk Feature#12328] Show warnings about vulnerable and no longer supported Ruby versions. Issue #12328 has been updated by Jeremy Evans. I am against ruby emitting warnings just because it thinks there may be a newer ruby version available. Cezary, if you want to only support newer versions of ruby in your gems, then just start using the newer features and set required_ruby_version in the gemspec as appropriate. If you are getting backlash from the community in doing so, the solution is not to modify the interpreter, but to stand your ground and tell the users that want to use your library on older ruby versions to fork the library. Likewise, for other libraries that value backwards compatibility, you are free to fork the library and update it so that it only works on recent ruby releases. Then users of those libraries can decide to switch to your fork if they share your values. IMO, dropping support for previous ruby releases is just a cost-benefit calculation. The benefit of dropping support for older rubies is the ability to use newer, non-backwards compatible ruby features (e.g. keyword arguments, Module#prepend), and the cost is that users that are forced to use older ruby versions are no longer able to use newer versions of the library. I think it's presumptuous to assume that just because you find the benefits outweigh the costs for your library, that all maintainers of other libraries would feel the same way about their libraries. ---------------------------------------- Feature #12328: Show warnings about vulnerable and no longer supported Ruby versions. https://bugs.ruby-lang.org/issues/12328#change-58392 * 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: