If a project passes the tests in Ruby 2.0.0-p648 and Ruby 2.3.1, does it make sense to also test with versions such as 2.1.8 and 2.2.3?
Has there been any language features that worked in Ruby 2.0 and Ruby 2.3 but were temporarily not working or worked differently in for example Ruby 2.2?
You should test your code for environments you intend it to be used in. Ruby language version is one thing that can vary. You might also consider testing against JRuby and Rubinius if your code is supposed to support it - e.g. it is provided as a public gem.
Logically, testing on earliest and latest versions should cover most failure scenarios with respect to language features (although not necessarily all language bugs since new ones can be introduced). As far as I know there has not been a Ruby feature that was deliberately added or removed in one version and then that decision reversed in a later version. Unless: Perhaps in your production code you are detecting a feature's existence and then using the feature in full - in which case an intermediate Ruby version which has the feature but not in its latest state could fail.
There may be other caveats too, and philosophically speaking when you start testing you want to avoid too much logical "this should work because . . ." thinking. The point of testing is to demonstrate that your code doesn't fail in ways you have covered (well, there's more depth to it than that, but the answer would get far too long if it dove into test philosophies). If you want to declare "works in all versions of Ruby MRI from 2.0.0 to 2.3.1" then you will feel safer making that statement if you have actually tested it. In fact when making such a statement in a public place, I would usually just say something closer to raw fact - "tested in versions 2.0.0, 2.1.4 and 2.3.1".
Obviously there are diminishing returns. If you have no problem in 2.1.9, it is very unlikely you will have a problem in 2.1.10 - at some point it will cost you more to check every minor variation, even just to look at the test results, than the benefit of extra coverage.
The usual answer to this problem is to test as many variations as your automated test environment can handle and you can be bothered to set up and maintain. If using multiple versions of Ruby is done for you in parallel by your test service provider - e.g. you are using Travis - then it is relatively cheap to test multiple versions. So you may as well get as much coverage on environment variations that you expect to see "in the wild" as you can be bothered to look at.
Related
We're using rack-test for our Cucumber specs. We've been trying to migrate over to Ruby 3 for a while now and the current issue is that the Cucumber tests crash due to rack-test using both keyword/positional args in their internal methods.
I'm up for patching it myself, but seeing how little activity there is on the repo (including PRs open for weeks/months) I fear that I'd do the work and there would be nobody to patch it.
The only alternatives I see are:
Do the work and pray there will be someone to review/merge the changes
Patch it locally & use the patched version locally from now on (yuck)
Find an alternative solution for rack-test
The last solution seems the best IMO. So, are there any alternatives?
As with all open source software, you have a few options:
Keep using the old software version (i.e. don't use ruby v3.0.0).
Hope that someone else updates the dependencies for you.
Do the update yourself.
Stop using the library.
At the moment, option 1 is totally viable; ruby 2.7 is still actively maintained, and support will probably continue until 2023-03-31. You could do this, simply hoping that option 2 becomes available soon.
The standard practice for option 3 is:
Fork the project, and make the fixes.
Open a pull request to the main repo with your fixes. Hopefully it gets merged.
In the meantime, if you need to be unblocked, reference your forked repo in other projects.
This is clearly more effort, but I wouldn't call it a "yuck" solution; not unless your changes are drastic/introduce compatibility issues with the main project, and the two branches diverge.
As for option 4, as with virtually any library replacement, there's always going to be some trade-off between compatibility/features, but clearly other testing frameworks do exist. It depends how you are actually using it. Your mileage may vary.
In summary, I can't really give an objective answer to such a subjective question, but my advice at the moment would be: If you have time/skill/motivation to update to ruby 3 right now, then fork the dependency and update it. (It's probably not a massive change needed!).
But if you lack the time/skill/motivation to do this, then just stick with ruby 2.7 for now.
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?
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.
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.
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? :)
I have a project with many Ruby files, loaded by external program with embedded Ruby interpreter (and some other libraries). I'm trying to use RubyMine and Rubocop to help with development, but the problem is that the said embedded interpreter is of version 1.9.2 and can't be upgraded in any way. Is it possible to still use the Rubocop or other linter inside RubyMine and at the same time to make sure the code is compatible with old interpreter?
Yes you can, Check this out and then let RuboCop know the oldest version of Ruby which your project supports with updating .rubocop.yml file:
AllCops:
TargetRubyVersion: 1.9
The short answer is that yes, it is possible to change the linter used in RubyMine, there are complete walk-throughs on JetBrains site explaining how. I don't know off the top of my head any linters that specifically work for pre-2.0 versions of Ruby, not to say they don't exist.
The longer answer is that it really won't make much difference if the interpreter is running through another program, and not using a real Ruby installation, and any linter is not going to reliably work for you. There will be plenty of code that a linter will still think is perfectly acceptable, but fail when running in an embedded VM.
# Linter thinks this perfectly fine, part of 1.9.2 standard library
require 'base64'
# Still thinks this perfectly fine. This all fails miserably though
Base64.encode64('My string')
The most obvious examples would be the entire standard library, gems, rake, and anything that is not part of the "core" library. Basic rule of thumb, if you have to require a script (excluding your project's local scripts), it is not going to work.
Another reason it could never be reliable is that you do not know if the embedded Ruby interpreter has been altered, or removed features from Ruby for their purposes, and a linter would have even less way of knowing that. Years ago I dabbled with the RPG Maker series, and discovered the hard way that their were certain built in features of Ruby that were removed (or at least hidden) from their custom build.
If you are familiar with Ruby, then you can obviously steer clear of the major and most common 2.0+ changes that Ruby implemented to the core library, but the only reliable way to know (even with a linter), is testing, which you will need to do anyway ( or at least you should). RubyMine has good support for automating this with Minitest and RSpec.
In Ruby Core, a new literal notation "foo"f for frozen strings have been proposed for Ruby 2.1, but now people are concerned that code written in such syntax would not be parsable by Ruby 2.0. Why is that an issue? Hasn't Ruby tried to be only backward compatible? That is, if code written in Ruby 2.0 can be parsed by Ruby 2.1 interpreter, isn't that enough? Why does code written in Ruby 2.1 have to be parsable by Ruby 2.0 interpreter?
That's a very good question. I have followed the core ML for a while and I believe the main concern here is that the new frozen literal syntax is a syntax change, not only a feature change.
Let me expand the answer a little bit. First of all, let's remember that we are talking about a minor version change, that is not supposed to break compatibility with previous code. Indeed, you may argue that in fact, this is not going to happen at all. Ruby 2.0 code will just work fine in Ruby 2.1, but not the opposite.
You also mentioned that is implicit that a new version will possibly include features not available in the previous version. But I believe here's exactly where the concerns are starting.
The new syntax is introducing not only a feature change but also a syntax change. It means that if you try to feed Ruby 2.0 parser with Ruby 2.1 code, it will possibly fail. And this may not be a good idea, for all the reasons we already know (compatibility, migration, maintenance, etc).
And this is quite different than when you create a new method in Ruby 2.1 that is not available to Ruby 2.0. In this case, it's true that 2.1 will have more features than 2.0, but if you feed the previous interpreter with the same code base, it will not complain. You didn't change the language syntax, you just enriched the core library. And, in this case, it's very easy to make your 2.0 code more similar to 2.1: just implement the missing methods.
This is not possible with a syntax change because you will need to reimplement the parser.
If you look at the Ruby changes under this point of you, you will see that a very few syntax changes were introduced between minor versions.
Changes like the stubby lambda, keyword arguments, new hash notation, they were all introduced with a major bump.
Generally speaking, syntax level changes may cause more maintenance issues compared to feature level changes. This is my interpretation of the reason behind the new frozen literal syntax and the reason why they ended up using .freeze instead of the new syntax. freeze already exists in previous Ruby version, but even if they would come with a completely new method, methods are not evaluated at parse time and they can be easily backported.
The answers I have in mind are:
easier migration from ruby 2.0 to 2.1
share code between ruby version
people seem to find the f-suffix ugly/confusing
Migration
When the syntax is parse-able by both ruby versions, it is one task less on the list to migrate from 2.0 to 2.1. Existing code may benefit from better frozen string handling without any changes.
Shared code between ruby versions
With a similar syntax, you can write ruby code (especially libraries), which work with multiple ruby version (2.0 and 2.1). This gives library developers a greater audience (and less versions to maintain for different ruby versions). The library user, however, has an easier time migrating from ruby 2.0 to 2.1. Still the ruby 2.1 version can benefit from better frozen string handling.
Personal taste
Reading through the ruby bug tracker, I see that some people seem to find the new syntax ugly/confusing. Here are some examples:
"[not using the f-suffix] looks like Ruby"
"The [f-suffix] notation is ugly."
"it is confusing about the character 'f'. For example, it remind 'Float'"
"I personally dislike prefix/suffix forms, they feel like u'str' in python"
"it looks very strange" (ok, this one is not from the tracker)
There are other people who like the new syntax. Well, this is subjective, but we are wondering why people complain, so it is a point :)
Does Ruby have any tools along the lines of pylint for analyzing source code for errors and simple coding standards?
It would be nice if it could be integrated with cruisecontrolrb for continuous integration.
Or does everyone write such good tests that they don't need source code checkers!
I reviewed a bunch of Ruby tools that are available here
http://devver.wordpress.com/2008/10/03/ruby-tools-roundup/
most of the tools were mentioned by webmat, but if you want more information I go pretty in depth with examples.
I also highly recommend using Metric-Fu it gives you a on gem/plugin install of 3 of the more popular tools and is built with cruisecontrolrb integration in mind.
The creator has a great post that should help get you up and running in no time.
http://jakescruggs.blogspot.com/2008/04/dead-simple-rails-metrics-with-metricfu.html
There has been a lot of activity in Ruby tools lately which I think is a good sign of a growing and maturing language.
Check these out:
on Ruby Inside, an article presenting Towelie, Flay and Simian, all tools to find code duplication
Towelie
flay
Simian (a more general tool that supports Ruby among other languages)
reek: a code smell detector for Ruby
Roodi: checks the style of your Ruby code
flog: a code complexity analyzer
rcov: will give you a C0 (if I remember correctly) code coverage analysis. But be careful though. 100% coverage is very costly and doesn't mean perfect code.
heckle: changes your code in subtle manners and runs your test suite to see if it catches it. Brutal :-)
Since they're all command-line tools they can all be integrated simply as cc.rb tasks. Just whip out your regex skillz to pick the important part of the output.
I recommend you first try them out by hand to see if they play well with your codebase and if you like the info they give you. Once you find a few that give you value, then spend time integrating them in your cc.
One recently-updated interesting-looking tool is Ruby Object Oriented Design Inferometer - roodi for short. It's at v1.3.0, so I'm guessing it's fairly mature.
I haven't tried it myself, because my code is of course already beyond reproach (hah).
As for test coverage (oh dear, I haven't tried this one either) there's rcov
Also (look, I am definitely going to try some of these today. One at least) you might care to take a look at flog and flay for another style checker and a refactoring candidate finder.
There's also the built-in warnings you can enable with a quick:
ruby -w
Or setting the global variable $VERBOSE to true at any point.
Code metrics on ruby toolbox website.
Rubocop is a widely-used static code analyzer.
I just released Excellent which implements several checks on Ruby code. It combines roodi, reek and flog and also adds some Rails specific checks:
gem sources -a http://gems.github.com
sudo gem install simplabs-excellent
May be helpful...