search

toland / patron

Ruby HTTP client based on libcurl
http://toland.github.com/patron/
MIT License
541 stars 73 forks source link

running tests with ruby 1.8 results in segfault #63

Closed pravi closed 8 years ago

pravi commented 12 years ago

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 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

That sounds good to me.

julik commented 8 years ago

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