From eaaa60ec44c6f77176bba462ad755ae400b97bdc Mon Sep 17 00:00:00 2001 From: Gonzalo Rodriguez Date: Mon, 2 Jul 2018 14:09:17 -0300 Subject: [PATCH] Stop running TravisCI against jRuby for now I am starting to find it difficult to argue in favor of having jruby in the list of TravisCI rubies. It adds a bit of extra cost in maintenance and time spent waiting build to finish, without feeling we're getting a lot out of it. Thus, the feeling is that it has low ROI. Reasons behind my feeling of not "getting a lot out of it" includes: - Almost never coming across a situation in which I thought to myself "Hey, with this change we're making the gem incompatible with jRuby" because most of the failures on jRuby builds where either heisenbugs and/or rvm installation problems with jRuby, at least in my experience - Usage share seems to be very very low, even compared to unmaintaned MRI version, according to some sources, e.g. https://semaphoreci.com/blog/2017/11/08/ruby-versions-used-in-commercial-projects-in-2017.html --- .travis.yml | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/.travis.yml b/.travis.yml index 6b99df2..27f22bb 100644 --- a/.travis.yml +++ b/.travis.yml @@ -6,17 +6,9 @@ rvm: - 2.5.1 - 2.4.4 - 2.3.7 - - jruby-9.1.16.0 before_install: - # For jruby we need to stick with rubygems 2.7.4 until - # https://github.com/rubygems/rubygems/issues/2188 - # is fixed and released. - # - # Without this workaround, for jruby builds, rubygems - # activates jruby stdlib minitest (v5.4.1) instead of the - # bundled version (v5.11.3). - - if [ "${TRAVIS_RUBY_VERSION:0:5}" = "jruby" ]; then gem update --system 2.7.4; else gem update --system; fi + - gem update --system - gem install bundler gemfile: