re: Any thoughts on Ruby 2.6? VIEW POST

TOP OF THREAD FULL DISCUSSION
re: Well, in theory you're supposed to have tests so failing tests should start breaking. But yeah, it's going to take work from some gem authors. The ...

In theory my tests should not test the core functionality of the language I use. I explicitly insist of removing such tests from the test suit during CRs. So no, tests won’t start breaking in the vast majority of the gems.

Also, as a maintainer of several OS gems I can tell that I don’t have time to run tests against each commit into core trunk, otherwise I would not be able to perform my regular duties.

Since triple-equal aka case-equal is one of the most powerful features of the language, very many gems use it to some extent. Luckily enough, not all of them deal with ranges, but I am positive that all the gems I maintain would break if they were to break Proc#=== behavior.

And, the last but not the least, that is not the first time they totally screw the version up. None of my gems worked on 2.3 when they broke __caller__ to return the same value as __method__. This is not exactly what I would expect from the mature enough language. Only Python did worse.

I agree you shouldn't test core functionalities but if something that returns true suddenly returns false some tests will break. If they don't maybe they're not writing the right tests.

I feel like a maintainer of a gem should keep an eye on the changelog of the language the library is written on. At least to check if there are new features that one can take advantage of.

Anyhow, I don't like either but I don't think it's an insane idea. There's no right time to fix a bad behavior people built their libraries on, unfortunately

Within ranges we don’t explicitly test boundaries. We test our internal behaviour for somewhat within the range and somewhat outside of it. Not the boundaries.

a maintainer of a gem should keep an eye on the changelog

In the ideal world she indeed should. Unfortunately, there are many other activities to be performed and I could dedicate some time to update my gems for the new Ruby version only when it’s released. The alternative would be to abandon gems support at all. I still have only 24 hrs/day and I do not even do ruby anymore. I feel like that is the common pattern among a part of ruby community.

There's no right time to fix a bad behavior people built their libraries on

Very true. The thing is you don’t fix it. You say “the implementation of that sucks, but bear with it.” Or you deprecate the behaviour, print boring warnings for at least one major version further and only then you change it. That is how it’s being done in languages made and supported with a care about end-users.

You’ll see how it would go with upgrades to 2.6.

Very true. The thing is you don’t fix it. You say “the implementation of that sucks, but bear with it.” Or you deprecate the behaviour, print boring warnings for at least one major version further and only then you change it.

Yeah, true that, they should have put warning signs everywhere for 2.6 and maybe fixed it in 2.7 (or Ruby 3?).

code of conduct - report abuse