Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update supported ruby versions #392

merged 3 commits into from Mar 22, 2019

Update supported ruby versions #392

merged 3 commits into from Mar 22, 2019


Copy link

@jdleesmiller jdleesmiller commented Mar 21, 2019

Many recent PRs had spurious CI failures due to end of life ruby versions in CI.

  1. The (recent) failures were on gem update --system for old versions of ruby that are end-of-life.

    Ruby versions < 2.3 are now end of life: and 2.3 is itself scheduled to be EOL on 31 Mar 2019.

  2. fixed FrozenError caused by frozen-string-literal #390 added workarounds to not run gem update --system on those old versions. However, looking at git blame, it looks like gem update --system was added a long time ago in 2bd6ebe. In Travis: JRuby code coverage possible using the --debug flag, drop a failing JDK variant, use Rubinius rbx-3 #346, 43f01f4 mentions that it shouldn't be needed and removes it but then brings it back in cbdea2a (without comment, even though the previous CI run passed without it).

    I have tried removing it again, and it does not seem to be required now --- both JRuby and MRI builds seem OK with just using the default rubygems version. So, in this PR I have removed it.

  3. I was instead going drop the EOL versions from travis, but in the gemspec we are still requiring ruby version >= 1.9.2, so I feel like we should continue testing on older versions until we bump that requirement.

    I found the discussion around Restore 1.9.3 and add 1.9.2 to .travis.yml #254 / Drop Ruby 1.9 support in changelog and gemspec #256, and it seems several users and contributors are of the opinion that dropping 1.9 from the test matrix, which was done because rubocop no longer supported 1.9, should have been a major version bump.

    My reading of the semver FAQ is that a major version bump is not required when a dependency is upgraded, but there are lengthy and interesting discussions about this, and I could be persuaded otherwise.

    For the moment, with gem update --system removed, the old ruby versions are not causing any problems, so I have left them in. If we want to upgrade rubocop again, which I think would be helpful for supporting frozen string literals (fixed FrozenError caused by frozen-string-literal #390 / Add test build with frozen strings #374), then we may need to drop them or remove rubocop as a dev dependency (it could e.g. go into the Gemfile in a group that would only be installed for some rubies, but this seems like a lot of complexity to support very old ruby versions).

  4. I reverted Move jruby to allow failures matrix #375 - the underlying JRuby bug now seems to be fixed, so we don't need to ignore it.

  5. The other source of spurious CI problems is coveralls: sometimes the coverage numbers drop even though no code has changed. I think we may need to enable parallel build support: --- otherwise, I think there is a race on which build finishes last (usually one of the JRuby builds). I'm not sure about this, but I would like to try it out.

@jdleesmiller jdleesmiller self-assigned this Mar 21, 2019
@jdleesmiller jdleesmiller removed their assignment Mar 22, 2019
@jdleesmiller jdleesmiller marked this pull request as ready for review March 22, 2019 14:04
Copy link
Member Author

Since this is internal-only, I'm going to go ahead and merge it.

@jdleesmiller jdleesmiller merged commit 8ece5c9 into master Mar 22, 2019
@jdleesmiller jdleesmiller deleted the update-ci branch March 22, 2019 14:13
@jdleesmiller jdleesmiller mentioned this pull request Jul 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

Successfully merging this pull request may close these issues.

None yet

1 participant