Ruby 1.9 not supported ONLY because of tins

[gorn]

Tins gem does not support ruby 1.9, which makese coveralls-ruby unusable with ruby 1.9. Given the nature of the gem, the support for at least 1.9.3 is desirable. It would be great to see whether the tins is really needed or if we can live without it of contribute the backwards compatibility to it, see flori/tins#15

[tagliala]

@gorn you should still be able to use the official gem

I'm for dropping all unsupported rubies, including 2.2

[gorn]

The idea was that it would gracefully transfer to new one, but I understand reasons against.

I am NOT for dropping support, for this reason: Testing and coverals are tools for manaining code which covers possibly longterm support. Therefore there might be valid reasons why a user of this gem might want to test older ruby as well (as it is not in his hands to simply upgrade). If it was any gem for more "on the edge" usage, than sure.

[AlexWayfer]

I am NOT for dropping support, for this reason: Testing and coverals are tools for manaining code which covers possibly longterm support.

Yeah, but:

1. Ruby ≤ 2.2 even has no security patches since March 2018 (LTS implies them, as I know)
2. Just don't update gem versions if you're not updating Ruby

[gorn]

You mean make Gemfile conditional on ruby version? I have never thought about this, it may work.

[AlexWayfer]

You mean make Gemfile conditional on ruby version?

No…

If project is old, and locked at the old version of Ruby — its bundle of gems should not be upgraded too.

If you're upgrading gems, especially to new major versions or replacements, be ready for breaking changes, like dropping support for unsupported software versions.

[gorn]

I have a project (gorn/rspreadsheet) which until now compiles fine with any even 1.9.3 with the same Gemfile for all versions. I thing that what you suggest is to make that Gemfile conditional on ruby version and in particular fir ruby 1.9 request older coverals-ruby. I am just mailing sure that this is what you suggest.

[AlexWayfer]

I have a project (gorn/rspreadsheet) which until now compiles fine with any even 1.9.3 with the same Gemfile for all versions.

Oh, it's a gem!

I thing that what you suggest is to make that Gemfile conditional on ruby version and in particular fir ruby 1.9 request older coverals-ruby. I am just mailing sure that this is what you suggest.

No, I thought you talked about application project, with Gemfile.lock. So, I just suggested to not update this .lock.

If you have a gem, that works with Ruby 1.9 — it's fine, but I recommend to move on and forget about this unsupported MRI version by Ruby Core. Ruby 2.0, 2.2 and further have a nice new syntax, optimizations, methods of core classes.

[tagliala]

term-ansicolor also requires Ruby 2.0

I would go for a condition in the Gemfile or you could fork this repository and allow older dependencies

[gorn]

@AlexWayfer with a minor exception, my code works in asll rubies without any change.

[pboling]

I've solved the tins issue in my flag_shih_tzu Gemfiles (see how here).

This is my support matrix. It took some fine tuning, but it is workable!

An upcoming release will drop support for old stuff, but, as this gem is used in many legacy projects, I didn't want to cut their legs off for no reason.

[gorn]

Thanks @pboling i think this is probably the way I should go - taking the whole matrix + excluding the unsupported combinations. It is kind of conditional gemfile in a way.