Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Breaking change for octokit in 0.16.1 #1033

Closed
Vedrillan opened this issue Sep 28, 2019 · 2 comments
Closed

Breaking change for octokit in 0.16.1 #1033

Vedrillan opened this issue Sep 28, 2019 · 2 comments

Comments

@Vedrillan
Copy link

Basic Info

  • Faraday Version: 0.16.1
  • Ruby Version: 2.6.4

Issue description

Been having issues related to faraday with a new project using octokit.

~/.rvm/gems/ruby-2.6.4/gems/octokit-4.14.0/lib/octokit/middleware/follow_redirects.rb:14:in `<module:Middleware>': superclass must be a Class (Faraday::DeprecatedConstant given) (TypeError)

Tested with 0.15.4 and there is no issue there.
If it is a desired breaking change then let me know, I will gladly report this to the octokit repository, maybe they will freeze faraday usage to a compatible version.

Steps to reproduce

Create a new ruby file, install octokit, which will depends at some point on faraday latest, then at line require octokit this error will happen.

BobbyMcWho added a commit to BobbyMcWho/faraday that referenced this issue Sep 28, 2019
BobbyMcWho added a commit to BobbyMcWho/faraday that referenced this issue Sep 28, 2019
zacikpa referenced this issue in crocs-muni/usable-cert-validation Sep 28, 2019
sushantdhiman added a commit to sequelize/sequelize.org that referenced this issue Sep 28, 2019
BobbyMcWho added a commit to BobbyMcWho/faraday that referenced this issue Sep 28, 2019
The version modeled off of activesupport's deprecations methods
was causing issues when classes inherited from the deprecated class.
Switch to a metaprogrammed class that warns upon initialization.

Failing spec for lostisland#1033

rename module to DeprecatedClass

Fix incorrect usage of rspec raise_error

WARNING: Using `expect { }.not_to raise_error(SpecificErrorClass)`
 risks false positives, since literally any other error would cause
 the expectation to pass, including those raised by Ruby
 (e.g. NoMethodError, NameError and ArgumentError), meaning the code
 you are intending to test may not even get reached. Instead consider
 using `expect { }.not_to raise_error` or
 `expect { }.to raise_error(DifferentSpecificErrorClass)`.
BobbyMcWho added a commit to BobbyMcWho/faraday that referenced this issue Sep 28, 2019
The version modeled off of activesupport's deprecations methods
was causing issues when classes inherited from the deprecated class.
Switch to a metaprogrammed class that warns upon initialization.

Failing spec for lostisland#1033

rename module to DeprecatedClass

Fix incorrect usage of rspec raise_error

WARNING: Using `expect { }.not_to raise_error(SpecificErrorClass)`
 risks false positives, since literally any other error would cause
 the expectation to pass, including those raised by Ruby
 (e.g. NoMethodError, NameError and ArgumentError), meaning the code
 you are intending to test may not even get reached. Instead consider
 using `expect { }.not_to raise_error` or
 `expect { }.to raise_error(DifferentSpecificErrorClass)`.

Update class doc
olleolleolle pushed a commit that referenced this issue Sep 28, 2019
The version modeled off of activesupport's deprecations methods
was causing issues when classes inherited from the deprecated class.
Switch to a metaprogrammed class that warns upon initialization.

Failing spec for #1033

rename module to DeprecatedClass

Fix incorrect usage of rspec raise_error

WARNING: Using `expect { }.not_to raise_error(SpecificErrorClass)`
 risks false positives, since literally any other error would cause
 the expectation to pass, including those raised by Ruby
 (e.g. NoMethodError, NameError and ArgumentError), meaning the code
 you are intending to test may not even get reached. Instead consider
 using `expect { }.not_to raise_error` or
 `expect { }.to raise_error(DifferentSpecificErrorClass)`.

Update class doc
garriguv added a commit to garriguv/danger-ruby-swiftformat that referenced this issue Sep 29, 2019
The latest version is breaking the specs.

See lostisland/faraday#1033
@marklchaves
Copy link

I ran into this issue yesterday. It broke my dev site. Just updated to 0.16.2. My dev site is back up. I.e., no more superclass must be a Class (Faraday::DeprecatedConstant given) error.

BobbyMcWho added a commit to BobbyMcWho/faraday that referenced this issue Sep 30, 2019
The version modeled off of activesupport's deprecations methods
was causing issues when classes inherited from the deprecated class.
Switch to a metaprogrammed class that warns upon initialization.

Failing spec for lostisland#1033

rename module to DeprecatedClass

Fix incorrect usage of rspec raise_error

WARNING: Using `expect { }.not_to raise_error(SpecificErrorClass)`
 risks false positives, since literally any other error would cause
 the expectation to pass, including those raised by Ruby
 (e.g. NoMethodError, NameError and ArgumentError), meaning the code
 you are intending to test may not even get reached. Instead consider
 using `expect { }.not_to raise_error` or
 `expect { }.to raise_error(DifferentSpecificErrorClass)`.

Update class doc
@iMacTia
Copy link
Member

iMacTia commented Oct 6, 2019

Hello everyone, we are really sorry for all the disruptions caused by the v0.16.x releases.
We've just performed a ROLLBACK RELEASE v0.17.0 which follows directly the latest working release v0.15.4.
Please update to that version to solve the backwards-compatibility issues.
More info here: https://github.com/lostisland/faraday/releases/tag/v0.17.0

@iMacTia iMacTia closed this as completed Oct 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants