Resolve bundler version issue and update list of tested Rubies

[vidarh]

Older Rubies are unsupported by bundler 2.0.1. This is attempting to resolve that by explicitly installing 1.17.2 after updating rubygems.

[ashmaroli]

IMHO, instead of all these changes, you could simply relax the constraint on Bundler in the Gemfile:
/~https://github.com/jneen/rouge/blob/e957c740ca85b3a96f2cea1e8e1eafbf9cb2abc4/Gemfile#L7

with either of the following:

• # open-ended declaration.
  # Allows all versions greater than or equal to `v1.15.0`
  gem 'bundler', '>= 1.15'

• # Allow all versions greater than or equal to `v1.15.0` but lesser than `v3.0.0`
  gem 'bundler', '>= 1.15', '< 3.0'

[vidarh]

@ashmaroli Good point. Testing that. Though <2.3 are unmaintained, and 2.3.x is close to EOL so might be worth considering removing those from the CI test either way, but might as well make those two separate considerations if we can. Thanks.

[vidarh]

@dblessing Drew, can you please have a look at this. This resolves the Travis CI issues, but there are a few different alternatives:

Option 1: We drop Ruby 2.0, 2.1, 2.2, 2.3. 2.0-2.2 are no longer maintained. 2.3.x receives security updates but is close to EOL. Dropping anything 2.3.x and down lets us otherwise continue as before and test with the newest applicable bundler version by just relaxing the bundler version criteria.

Option 2: We drop Ruby 2.0-2.2, but not 2.3. This requires falling down to an older version of bundler if installing the newest version fails (gem install bundler || gem install bundler -v v1.15 in .travis.yml).

Option 3: We retain CI tests on all versions. This requires option 2 and allowing "gem update --system| to fail in .travis.yml (the "|| true"), as the new versions of rubygems do not support anything below 2.3.x.

I'm leaning towards option 2. 2.3.x is notionally supported, and falling back on an older bundler should be safe. Dropping 2.2 and below seems pragmatic at this point.

If you prefer option 3 and want to retain support for <=2.2 I can see if we can selectively let "gem update --system" fail (or not run) for those versions only before you merge anything.

If you agree with option 2, then let me know and I'll produce a squashed commit for that.

Either way getting this out of the way seems essential before we move forward with merging anything else.

[vidarh]

@ashmaroli So, that sort-of helped. It helped for 2.3, but as you can see from my comment above the problem for 2.2 and below is that additionally newer versions of rubygems fails there. But thanks for the suggestion anyway - keeping 2.3.x as long as it's still somewhat supported is good 👍

[ashmaroli]

@vidarh You're welcome. 😃
I would recommend stop testing for versions older than Ruby 2.3 in this PR. The added advantage is that:

• Less time gets spent on CI builds.
• The diff here gets more focused to just the bare minimum change required.

In a future PR, you could drop support for EOL Rubies entirely by enforcing >=2.4.0 in the gemspec. The advantage with this is that then the gem could move to using newer syntaxes like the safe navigation operator (&.), sqiggly heredocs (<<~) from Ruby 2.3 and also using the faster String#match? etc from Ruby 2.4

[marius-balteanu]

Another way to fix the Travis build is marius-balteanu@07ccf80
which passes on all Ruby versions (including 2.6).

https://travis-ci.org/marius-balteanu/rouge/builds/487840500

I can create a PR if is wanted.

Regarding supported Ruby versions, I think only EOL versions should be dropped (#1081)

[pyrmont]

This has been addressed by #1110 and #1128. As discussed in #1115, older versions of Ruby will continue to be part of the CI builds for now.

Thanks @vidarh and @ashmaroli for your work on this. Sorry it took so long :(

[ashmaroli]

@pyrmont No probs. Glad to see this project active again.