Permalink
Browse files

Remove official support for JRuby and Rubinius

  • Loading branch information...
1 parent 0673052 commit 75c8147b3dd35c7ed30dfd151427f6f98beb6e22 @sferik committed Jul 28, 2012
Showing with 5 additions and 9 deletions.
  1. +4 −0 .travis.yml
  2. +1 −9 README.md
View
@@ -2,6 +2,10 @@ language: ruby
matrix:
allow_failures:
- rvm: ruby-head
+ - rvm: jruby-18mode
+ - rvm: jruby-19mode
+ - rvm: rbx-18mode
+ - rvm: rbx-19mode
rvm:
- jruby-18mode
- jruby-19mode
View
@@ -283,19 +283,11 @@ Ideally, a bug report should include a pull request with failing specs.
## Supported Ruby Versions
This library aims to support and is [tested against][travis] the following Ruby
-implementations:
+version:
* Ruby 1.8.7
* Ruby 1.9.2
* Ruby 1.9.3
-* [JRuby][]
-* [Rubinius][]
-
-[jruby]: http://www.jruby.org/
-[rubinius]: http://rubini.us/
-
-If something doesn't work on one of these interpreters, it should be considered
-a bug.
This library may inadvertently work (or seem to work) on other Ruby
implementations, however support will only be provided for the versions listed

4 comments on commit 75c8147

Any particular reason for dropping JRuby support? Are there known incompatibilities?

Owner

sferik replied Aug 1, 2012

The build was regularly failing due to JRuby and Rubinius failures that had absolutely nothing to do with this library. For example, the Rubinius build is currently failing during the bundle install command with the error:

/home/vagrant/.rvm/src/rbx-head/staging/bin/rbx: bad interpreter: No such file or directory

As far as I know, this library still works with Rubinius but I'm not willing to have a failing build for this project as the result of a Rubinius issue. There's a longer discussion of this issue here. The short version is: I see it as my responsibility to make my library compatibile with Ruby, as defined by MRI. If tests pass on MRI but not Rubinius or JRuby, that's a bug in Rubinius or JRuby, not in this library. The build status should reflect bugs in this project, not bugs in other projects.

Makes sense. I wasn't sure if the reason was bugs in these implementations or if there was a plan to do something that is specifically incompatible with JRuby (or Rubinius) - e.g. aggressive use of ObjectSpace, fork/exec, etc. I'm using it on JRuby in production, so I'll just keep a close eye on the CI for it.

Owner

sferik replied Aug 1, 2012

Believe it or not, there actually is a reference to ObjectSpace in the library, but it should still work on JRuby and Rubinius. My intent is to maintain compatibility with JRuby and Rubinius, even if it requires jumping through some hoops or making the code a bit less elegant. We already do a bit of this to maintain Ruby 1.8 compatibility. That said, I'm planning to drop support for Ruby 1.8 in the next major version of the gem, since 1.8.7 is scheduled to stop being maintained in June of next year. Support for 1.8 will continue to be maintained, at least through that point. I expect to see most of the remaining Ruby 1.8 stragglers get onboard the Ruby 1.9 train shortly after Rails 4 is released, which will drop support for Ruby versions < 1.9.3.

Please sign in to comment.