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

Set a fixed API version #621

Closed
driesvints opened this issue Mar 18, 2019 · 0 comments
Closed

Set a fixed API version #621

driesvints opened this issue Mar 18, 2019 · 0 comments
Milestone

Comments

@driesvints
Copy link
Member

There have been numerous issues with Stripe API updates in the past. Here's some:

The problem with this is that Cashier currently tries to be compatible with numerous API updates. We do, however started testing against a specific version (usually the latest one) since #603

But because we don't enforce this version through the SDK, Stripe can still release updates and people can update the API version themselves which will cause breakages like #617.

A possible solution for this is to enforce a version through the SDK so the library is always compatible with the specific version of the API that it uses. The problem with this however is that if users are extending Cashier and using API specific functionality will see their apps break if we upgrade to a new version.

I do, however, believe this is the correct way forward. This would mean that we need to set a specific version for Cashier through the SDK. Making this configurable doesn't makes any sense since if someone would change this to a version that has breakages for Cashier, Cashier itself wouldn't be usable.

By setting a specific version this would prevent breakages like above and would allow us to adopt our own upgrade path as we see fit. This would mean we could only adopt breaking API version changes in new minor versions which SemVer allows for. People extending the library however, need to be aware that this can happen and need to be aware to not upgrade blindly. SemVer allows for us to upgrade dependencies as we see fit as long as we don't alter the public API of Cashier itself: https://semver.org/#what-should-i-do-if-i-update-my-own-dependencies-without-changing-the-public-api

Because of the above reason we may adopt this as soon as the next minor version of Cashier. But for the sake of explicitness and the fact that Cashier handles very sensitive data it might be better to make this change in the next major version and add a general note to the docs about Stripe versions and upgrading minor versions when a Stripe API update to Cashier was performed.

@driesvints driesvints changed the title Maybe set a fixed API version Set a fixed API version Apr 11, 2019
@driesvints driesvints added this to the v10 milestone Apr 11, 2019
driesvints added a commit that referenced this issue Apr 15, 2019
This commit sets a fixed Stripe API version for all Stripe API calls made from Cashier. It's being passed as an option to all calls together with the api key. The way options are handled has also been refactored so this is now entirely done on the Cashier class while keeping the Billable entity free from any configuration related options. This may later still be changed when a config file for Cashier is introduced: #531

Closes #621 and #642
driesvints added a commit that referenced this issue Apr 16, 2019
This commit sets a fixed Stripe API version for all Stripe API calls made from Cashier. It's being passed as an option to all calls together with the api key. The way options are handled has also been refactored so this is now entirely done on the Cashier class while keeping the Billable entity free from any configuration related options. This may later still be changed when a config file for Cashier is introduced: #531

Closes #621 and #642
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant