1

I am using a quite recent version of ruby (2.5.1) but some old gems. I am having some issues. I was wondering, is it correct that some gems work only with certain versions of ruby?

If a gem worked with ruby 2.3.0, is it true that it will definitely work with 2.5.1 (i.e. because 2.5.1 > 2.3.0)? Or is that not always the case?

I guess what I'm asking is are newer ruby versions always backwards compatible with older gems?

stevec
  • 41,291
  • 27
  • 223
  • 311
  • 1
    Most likely but not necessarily. The most vivid example from near past would be `Range#cover?` that changed the behaviour in 2.6. – Aleksei Matiushkin Feb 16 '19 at 12:25
  • 1
    Another example might be that gems depending on `Bignum` or `Fixnum` display a warning since Ruby 2.4, because these classes are deprecated and you should use `Integer` instead. It is just a question of time until these classes will be removed from Ruby completely and then old gems depending on them will not only raise warnings but fail. – spickermann Feb 16 '19 at 13:23
  • the answer to this is pretty much no for any language in my experience. change is constant and so is entropy. – engineerDave Feb 16 '19 at 20:12

3 Answers3

2

If a gem worked with ruby 2.3.0, is it true that it will definitely work with 2.5.1

This is not correct. Programming languages are evolving while growing. This means language maintainers are doing lots of improvements or refactorings that they are new features or removing old components from the language. When the language community announces for new features or removing old feature such as Fixnum in ruby, the developers should follow the instructions and refactor their codebase accordingly. In other words, developers should have a good test coverage to detect any fail and fix it instantly.

In your scenario, as well as I understand you do not have a test coverage. The only but the simple thing should do is just upgrade your gems' versions to latest.

zeitnot
  • 1,304
  • 12
  • 28
1

Gem is simply a plug-in library written in Ruby.

Of course, Ruby is developing, new features are appearing, old ones are disappearing.

It's best practice to specify Ruby version in .gemspec file. For example, like this one.

But if not, then you have to manually check the performance. So you can read gem source code or try to use your gem and check it.

For automation, of course, it is best to use tests.

mechnicov
  • 12,025
  • 4
  • 33
  • 56
1

Starting at Ruby 2.1.0 the version policy has been that a change in the MINOR version may introduce API breaking changes.

Should any gem happen to use an API that changes, an incompatibility will arise.

The MINOR version number has changed twice between 2.3.* and 2.5.* so even if a gem happens to have been written in accordance with the documented API, there's no guarantee that it will continue to work unless the gem's maintainer takes the effort to test the gem (and upgrade it if necessary). Automated test suites help a lot.

A standard way to document version compatiblity that is actually tested against is by providing required_ruby_version in .gemspec files.

Interestingly, if a particular gem is really badly written, I imagine it might break even between compatible versions of Ruby. That's not something I've encountered in the Ruby ecosystem but I've made a similar mistake writing Java code (and Java is famous for its backward compatibility) where my own code accidentally used a class that wasn't part of the API. There are many gems. Who knows what's out there? :)

toniedzwiedz
  • 17,895
  • 9
  • 86
  • 131