Drop support for Ruby 2.0, 2.1, and 2.2 #148
Conversation
These Ruby versions are no longer supported. Including these in our CI builds slows the feedback cycle and introduces a maintenance burden for which there is no clear user base. 1. Ruby 2.0 on Februrary 24th, 2016 2. Ruby 2.1 on April 1st, 2017 3. Ruby 2.2 on June 20th, 2018 [1] https://www.ruby-lang.org/en/news/2016/02/24/support-plan-of-ruby-2-0-0-and-2-1/ [2] https://www.ruby-lang.org/en/news/2017/04/01/support-of-ruby-2-1-has-ended/ [3] https://www.ruby-lang.org/en/news/2018/06/20/support-of-ruby-2-2-has-ended/
1 similar comment
|
shrug For the base gem of the tool chain that I made for my QA activities, I support all the 'major' versions of Ruby. So, 1.8.7, 1.9.3, and the more recent 2.x ones. However, I do this mostly as an exercise in backwards compatibility and because the maintenance burden is pretty low due to the fact that it's all just (more or less) parsing text, so there isn't much to go wrong. For a more complex gem like 1.x, we hardly knew ye. Long live 2.x! Luckily, major versions are cheap with semantic versioning. ;) |
|
Thanks for the response + review. Was planning on leaving this up for a week just in case there were any other strong opinions from others. Happy to merge at this point. |
After sending TERM to a leader process, `::Process.waitpid2(_pid, ::Process::WNOHANG | ::Process::WUNTRACED)` appears to just return nil under ruby 2.6. This causes process.stop to send TERM to the process, poll (unsuccessfully) for the exit status until the timeout is hit, then send KILL.
Update ruby-childprocessto 3.0.0. ### Version 3.0.0 / 2019-09-20 * [#156](enkessler/childprocess#156 unused `rubyforge_project` from gemspec * [#160](enkessler/childprocess#160): Remove extension to conditionally install `ffi` gem on Windows platforms * [#160](enkessler/childprocess#160): Remove runtime dependency on `rake` gem ### Version 2.0.0 / 2019-07-11 * [#148](enkessler/childprocess#148): Drop support for Ruby 2.0, 2.1, and 2.2 * [#149](enkessler/childprocess#149): Fix Unix fork reopen to be compatible with Ruby 2.6 * [#152](https://github.com/enkessler/childprocess/pull/152)/[#154](https://github.com/enkessler/childprocess/pull/154): Fix hangs and permission errors introduced in Ruby 2.6 for leader processes of process groups ### Version 1.0.1 / 2019-02-03 * [#143](enkessler/childprocess#144): Fix installs by adding `rake` gem as runtime dependency * [#147](enkessler/childprocess#147): Relax `rake` gem constraint from `< 12` to `< 13` ### Version 1.0.0 / 2019-01-28 * [#134](enkessler/childprocess#134): Add support for non-ASCII characters on Windows * [#132](enkessler/childprocess#132): Install `ffi` gem requirement on Windows only * [#128](enkessler/childprocess#128): Convert environment variable values to strings when `posix_spawn` enabled * [#141](enkessler/childprocess#141): Support JRuby on Java >= 9
These Ruby versions are no longer supported. Including these in our CI builds slows the feedback cycle and introduces a maintenance burden for which there is no clear user base.
These Rubies have not been supported for quite some time:
[1] https://www.ruby-lang.org/en/news/2016/02/24/support-plan-of-ruby-2-0-0-and-2-1/
[2] https://www.ruby-lang.org/en/news/2017/04/01/support-of-ruby-2-1-has-ended/
[3] https://www.ruby-lang.org/en/news/2018/06/20/support-of-ruby-2-2-has-ended/
Opening this for any comments. Is there a good reason to maintain support for these versions?
Once merged, this would likely prompt a bump to version 2.0.0, given the introduction of the Ruby version constraint to the gemspec.