running tests with ruby 1.8 results in segfault #63

Closed
pravi opened this Issue Oct 30, 2012 · 5 comments

3 participants

@pravi

Running tests for ruby1.8 using debian/ruby-tests.rake ...
/usr/bin/ruby1.8 -S rspec ./spec/util_spec.rb ./spec/response_spec.rb ./spec/request_spec.rb ./spec/patron_spec.rb ./spec/session_spec.rb
/media/forge/debian/diaspora/ruby-patron-0.4.18/spec/../ext/patron/session_ext.so: [BUG] Segmentation fault
ruby 1.8.7 (2012-02-08 patchlevel 358) [x86_64-linux]

rake aborted!
/usr/bin/ruby1.8 -S rspec ./spec/util_spec.rb ./spec/response_spec.rb ./spec/request_spec.rb ./spec/patron_spec.rb ./spec/session_spec.rb failed

Tasks: TOP => default => spec
(See full trace by running task with --trace)

Tests are running fine with ruby 1.9

/usr/bin/ruby1.9.1 -I/usr/lib/ruby/vendor_ruby /usr/lib/ruby/vendor_ruby/gem2deb/test_runner.rb
Running tests for ruby1.9.1 using debian/ruby-tests.rake ...
/usr/bin/ruby1.9.1 -S rspec ./spec/util_spec.rb ./spec/response_spec.rb ./spec/request_spec.rb ./spec/patron_spec.rb ./spec/session_spec.rb
.........................................................

Finished in 1.72 seconds
57 examples, 0 failures

@julik
Collaborator

@toland what should the minimum guaranteed supported Ruby be for patron? I've set it up with 1.9.3 on Travis, is 1.8 support still a priority?

@toland
Owner

This issue is kinda old, but it is a good question to have answered either way. My opinion is that the last 1.8 release was about 3 years ago and everything older than 2.1 is EOL. I would prioritize support for 2.1, 2.2 and 2.3. 1.9 and 2.0 would be supported on a "best effort" basis. In other words, as long as it isn't a detriment to the product to continue supporting them we will, but at some point in the near future we will probably drop support. 1.8 is old enough at this point that I don't see a benefit to supporting it.

@julik Does that seem reasonable?

@julik
Collaborator

I think the best would be to mandate compatibility with 1.9.3 for the 1.x release, and to freeze the API soon-ish to roll out that and explicitly drop 1.8 compatibility there. Then people who adhere to semver in their dependencies but still run on 1.8 will not have reinstall breakage.

@toland
Owner

That sounds good to me.

@julik
Collaborator

@pravi I think we will consider 1.8 support deprecated. If this is still relevant for you, please reopen.

@julik julik closed this May 14, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment