-
Notifications
You must be signed in to change notification settings - Fork 529
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
Semver concerns #982
Comments
Regarding HTTPotion, it seems like it was only changed in the tests. Otherwise, the default HTTP client still seems to be Hackney. The changelog entry is a bit misleading. |
Ah gotcha . Yea that's quite misleading . Might want to update the change log then as it for us quite a bit concerned with the changes |
I don't really agree that no longer supporting a deprecated version of Elixir should be a new major version number (though I understand the point of view). The fact that the language version itself is no longer receiving security patches means that upgrading that should be a much higher priority than sticking to the latest version of ex_aws. And on the other hand, if we did increment the major version, bumping the minimum supported Elixir version to be the...minimum supported Elixir version (if you follow me) would mean a new major version every six months, which would be a bit silly. More than happy to fix up the changelog, though - I'll tweak it shortly. |
First thank you for your work on the library.
So I see the new version of ex_aws was push as 2.5 with the following
First one is a breaking change so should likely be a major release since it is not backward compatible possibly
the 2nd one is even more a problem as Req does not use the same adapter underlying than HTTPotion (Finch vs hackney I believe) . there are some risk of breaking change on how pull, and configurations are done. Seems like another breaking change
based on https://semver.org/, it seems to me that a major would have been a bit of a better choice? While the API may not have changed, the actual client as a default might behave very differently in production (performance, timeout, configuration, etc..) . It might be backward compatible from the internal api point of view, but if feels that there is a risk still (pool will be have differently too)
The text was updated successfully, but these errors were encountered: