Update README.md

Co-authored-by: anniel-stripe <[email protected]>

README.md

@@ -122,7 +122,7 @@ const customerEmail: string = (paymentIntent.customer as Stripe.Customer).email;
 
 The Typescript types in stripe-node always reflect the latest shape of the Stripe API. When the Stripe API changes in a [backwards-incompatible way](https://stripe.com/docs/upgrades#what-changes-does-stripe-consider-to-be-backwards-compatible), there is a new Stripe API version, and we release a new major version of stripe-node. Sometimes, though, the Stripe API changes in a way that weakens the guarantees provided by the Typescript types, but that cannot result in any backwards incompatibility at runtime. For example, we might add a new enum value on a response, along with a new parameter to a request. Adding a new value to a response enum weakens the Typescript type. However, if the new enum value is only returned when the new parameter is provided, this cannot break any existing usages and so would not be considered a breaking API change. In stripe-node, we do NOT consider such changes to be breaking under our current versioning policy. This means that you might see new type errors from Typescript as you upgrade minor versions of stripe-node, that you can resolve by adding additional type guards.
 
-Please feel welcome to share your thoughts about the versioning policy in a Github issue. For now, we judge it to be a lesser evil than the two alternatives: outdated, inaccurate types, or vastly more frequent major releases, which would distract from the potentially-much-more-disruptive breaking changes with runtime implications.
+Please feel welcome to share your thoughts about the versioning policy in a Github issue. For now, we judge it to be better than the two alternatives: outdated, inaccurate types, or vastly more frequent major releases, which would distract from any future breaking changes with potentially more disruptive runtime implications.
 
 ### Using Promises