breaking changes when fixing a bug

Author: sentrivana

develop-docs/sdk/processes/breaking_changes.mdx

@@ -40,7 +40,9 @@ Naturally, the language of your SDK and the community around it also affects wha
 
 ### Changes in the Product
 
-We also need to be mindful of what the SDK change might cause in the product. Sometimes we're forcing users to make changes in their use of Sentry because we, for example, broke a dashboard by renaming a span attribute. However, we also don't want to be in a position where we can't fix an attribute name without releasing a new major version of the SDK. Having to adopt a new major version every month is also not great UX.
+We also need to be mindful of what the SDK change might cause in the product. Sometimes we're forcing users to make changes in their use of Sentry because we, for example, broke a dashboard by renaming a span attribute. However, we also don't want to be in a position where we can't fix an attribute name without releasing a new major version of the SDK. Having to adopt a new major version every month is also not great UX in most languages.
+
+An additional complicating factor is if removing an attribute or stopping to send certain spans is needed to fix a severe bug, like an SDK-induced app crash or hang. You should discuss with your teammates whether breaking SDK behavior as a knock-on effect from a bugfix warrants a major release.
 
 In general, we consider changes to the following product-side features potentially problematic:
 - **Grouping:** An SDK change might result in error events being grouped differently, because we remove, add or change some of the data on the event that is used in the grouping algorithm on the server. When you think a change might affect grouping, it's recommended to try the change yourself and check in Sentry to see if grouping is preserved.