You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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: #531Closes#621 and #642
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: #531Closes#621 and #642
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.
The text was updated successfully, but these errors were encountered: