From 33af937bd9d64920a52712db5e0be3c20ca35a16 Mon Sep 17 00:00:00 2001 From: Marcos Castany Date: Fri, 31 Jan 2025 20:24:08 +0100 Subject: [PATCH 1/7] Added breaking change definition --- docs/revenuecat-support/breaking-changes.md | 57 +++++++++++++++++++++ 1 file changed, 57 insertions(+) create mode 100644 docs/revenuecat-support/breaking-changes.md diff --git a/docs/revenuecat-support/breaking-changes.md b/docs/revenuecat-support/breaking-changes.md new file mode 100644 index 00000000..8af646dc --- /dev/null +++ b/docs/revenuecat-support/breaking-changes.md @@ -0,0 +1,57 @@ +--- +title: Breaking Changes Policy +sidebar_label: Breaking Changes +slug: breaking-changes +excerpt: Learn about breaking changes in RevenueCat +--- + +At RevenueCat, we strive to provide a stable and reliable platform for developers integrating in-app subscriptions. To ensure smooth integrations while maintaining the flexibility to improve our platform, we have clear guidelines on what constitutes a breaking change and what does not. + +## Semantic Versioning (SemVer) + +We follow Semantic Versioning (SemVer) for our SDKs to ensure predictable and transparent versioning. This means: + +- Major versions (X.0.0) may introduce breaking changes. + +- Minor versions (X.Y.0) introduce backwards-compatible new features. + +- Patch versions (X.Y.Z) contain backwards-compatible bug fixes and improvements. + +## What is a backwards compatible change? + +The following types of changes are not considered breaking: + +1. Additive API changes, such as: + + - Adding new optional fields to API responses. + + - Introducing new endpoints without modifying existing ones. + + - Expanding webhook event payloads with additional fields. + +2. Introducing new SDK methods that do not affect existing ones. + +3. Bug fixes and performance improvements that do not alter documented behaviors. + +4. Changes to internal logic that do not affect the API contract or documented SDK behavior. + +5. Deprecating features with proper notice while keeping existing functionality intact during a transition period. + +6. Updating documentation to clarify existing behaviors without modifying the implementation. + +## Deprecation and Migration Policy + +When a breaking change is necessary, we follow these best practices: + +- Deprecation Notices: We provide advance notice through our changelogs, documentation, and direct customer communications. + +- Grace Periods: Wherever possible, we maintain backward compatibility and provide transition periods for developers to update their integrations. + +- Versioning: Breaking changes may be introduced in new major versions of our SDKs or API versions, ensuring that existing implementations continue to function as expected. + +- Migration Guides: We provide clear upgrade paths and documentation to help developers adapt to changes. + +Our goal is to minimize disruptions while ensuring RevenueCat continues to evolve and improve. If you have any concerns about a potential breaking change, please reach out via our support channels or check our changelog for the latest updates. + +For further clarification or to discuss how a change might impact your integration, feel free to contact us! + From d56eeea0ae231b87e6ae0bd825911f76987e4609 Mon Sep 17 00:00:00 2001 From: Marcos Castany Date: Fri, 31 Jan 2025 20:34:53 +0100 Subject: [PATCH 2/7] Added sidebar --- sidebars.js | 1 + 1 file changed, 1 insertion(+) diff --git a/sidebars.js b/sidebars.js index a7d13a54..72493c8f 100644 --- a/sidebars.js +++ b/sidebars.js @@ -511,6 +511,7 @@ const supportCategory = Category({ items: [ Page({ slug: "general-troubleshooting" }), Page({ slug: "support-first-steps" }), + Page({ slug: "breaking-changes" }), ], }); From 40efc930a77f1427c51b54968c153397736a60ad Mon Sep 17 00:00:00 2001 From: Marcos Castany Date: Fri, 31 Jan 2025 20:39:57 +0100 Subject: [PATCH 3/7] Added link --- docs/revenuecat-support/breaking-changes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/revenuecat-support/breaking-changes.md b/docs/revenuecat-support/breaking-changes.md index 8af646dc..3e405728 100644 --- a/docs/revenuecat-support/breaking-changes.md +++ b/docs/revenuecat-support/breaking-changes.md @@ -9,7 +9,7 @@ At RevenueCat, we strive to provide a stable and reliable platform for developer ## Semantic Versioning (SemVer) -We follow Semantic Versioning (SemVer) for our SDKs to ensure predictable and transparent versioning. This means: +We follow [Semantic Versioning (SemVer)](https://semver.org/) for our SDKs to ensure predictable and transparent versioning. This means: - Major versions (X.0.0) may introduce breaking changes. From 9236dc6ef586c085d4802cece962f51e0867fa96 Mon Sep 17 00:00:00 2001 From: Marcos Castany Date: Fri, 31 Jan 2025 20:49:53 +0100 Subject: [PATCH 4/7] Subitems --- docs/revenuecat-support/breaking-changes.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/revenuecat-support/breaking-changes.md b/docs/revenuecat-support/breaking-changes.md index 3e405728..31910876 100644 --- a/docs/revenuecat-support/breaking-changes.md +++ b/docs/revenuecat-support/breaking-changes.md @@ -23,11 +23,11 @@ The following types of changes are not considered breaking: 1. Additive API changes, such as: - - Adding new optional fields to API responses. + 1. Adding new optional fields to API responses. - - Introducing new endpoints without modifying existing ones. + 2. Introducing new endpoints without modifying existing ones. - - Expanding webhook event payloads with additional fields. + 3. Expanding webhook event payloads with additional fields. 2. Introducing new SDK methods that do not affect existing ones. From f9e7549f800fc6eaa6a5a38413b8392e1f3a728a Mon Sep 17 00:00:00 2001 From: Marcos Castany Date: Fri, 31 Jan 2025 20:56:26 +0100 Subject: [PATCH 5/7] Remove spaces --- docs/revenuecat-support/breaking-changes.md | 19 +++---------------- 1 file changed, 3 insertions(+), 16 deletions(-) diff --git a/docs/revenuecat-support/breaking-changes.md b/docs/revenuecat-support/breaking-changes.md index 31910876..81809101 100644 --- a/docs/revenuecat-support/breaking-changes.md +++ b/docs/revenuecat-support/breaking-changes.md @@ -12,9 +12,7 @@ At RevenueCat, we strive to provide a stable and reliable platform for developer We follow [Semantic Versioning (SemVer)](https://semver.org/) for our SDKs to ensure predictable and transparent versioning. This means: - Major versions (X.0.0) may introduce breaking changes. - - Minor versions (X.Y.0) introduce backwards-compatible new features. - - Patch versions (X.Y.Z) contain backwards-compatible bug fixes and improvements. ## What is a backwards compatible change? @@ -22,21 +20,13 @@ We follow [Semantic Versioning (SemVer)](https://semver.org/) for our SDKs to en The following types of changes are not considered breaking: 1. Additive API changes, such as: - - 1. Adding new optional fields to API responses. - - 2. Introducing new endpoints without modifying existing ones. - - 3. Expanding webhook event payloads with additional fields. - + 1. Adding new optional fields to API responses. + 2. Introducing new endpoints without modifying existing ones. + 3. Expanding webhook event payloads with additional fields. 2. Introducing new SDK methods that do not affect existing ones. - 3. Bug fixes and performance improvements that do not alter documented behaviors. - 4. Changes to internal logic that do not affect the API contract or documented SDK behavior. - 5. Deprecating features with proper notice while keeping existing functionality intact during a transition period. - 6. Updating documentation to clarify existing behaviors without modifying the implementation. ## Deprecation and Migration Policy @@ -44,11 +34,8 @@ The following types of changes are not considered breaking: When a breaking change is necessary, we follow these best practices: - Deprecation Notices: We provide advance notice through our changelogs, documentation, and direct customer communications. - - Grace Periods: Wherever possible, we maintain backward compatibility and provide transition periods for developers to update their integrations. - - Versioning: Breaking changes may be introduced in new major versions of our SDKs or API versions, ensuring that existing implementations continue to function as expected. - - Migration Guides: We provide clear upgrade paths and documentation to help developers adapt to changes. Our goal is to minimize disruptions while ensuring RevenueCat continues to evolve and improve. If you have any concerns about a potential breaking change, please reach out via our support channels or check our changelog for the latest updates. From 0a24b7a1bc1122edfc5334cd4374cd0253ad2510 Mon Sep 17 00:00:00 2001 From: Marcos Castany Date: Tue, 4 Feb 2025 21:37:32 +0100 Subject: [PATCH 6/7] Update docs/revenuecat-support/breaking-changes.md Co-authored-by: Muhammad-Sharif Moustafa --- docs/revenuecat-support/breaking-changes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/revenuecat-support/breaking-changes.md b/docs/revenuecat-support/breaking-changes.md index 81809101..517de310 100644 --- a/docs/revenuecat-support/breaking-changes.md +++ b/docs/revenuecat-support/breaking-changes.md @@ -40,5 +40,5 @@ When a breaking change is necessary, we follow these best practices: Our goal is to minimize disruptions while ensuring RevenueCat continues to evolve and improve. If you have any concerns about a potential breaking change, please reach out via our support channels or check our changelog for the latest updates. -For further clarification or to discuss how a change might impact your integration, feel free to contact us! +For further clarification or to discuss how a change might impact your integration, feel free to [contact us](https://app.revenuecat.com/settings/support)! From a0153e5899eb28d6258a2ea302c744db7b71b42a Mon Sep 17 00:00:00 2001 From: Marcos Castany Date: Tue, 4 Feb 2025 21:37:39 +0100 Subject: [PATCH 7/7] Update docs/revenuecat-support/breaking-changes.md Co-authored-by: Muhammad-Sharif Moustafa --- docs/revenuecat-support/breaking-changes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/revenuecat-support/breaking-changes.md b/docs/revenuecat-support/breaking-changes.md index 517de310..36db2412 100644 --- a/docs/revenuecat-support/breaking-changes.md +++ b/docs/revenuecat-support/breaking-changes.md @@ -38,7 +38,7 @@ When a breaking change is necessary, we follow these best practices: - Versioning: Breaking changes may be introduced in new major versions of our SDKs or API versions, ensuring that existing implementations continue to function as expected. - Migration Guides: We provide clear upgrade paths and documentation to help developers adapt to changes. -Our goal is to minimize disruptions while ensuring RevenueCat continues to evolve and improve. If you have any concerns about a potential breaking change, please reach out via our support channels or check our changelog for the latest updates. +Our goal is to minimize disruptions while ensuring RevenueCat continues to evolve and improve. If you have any concerns about a potential breaking change, please reach out via [our support channels](https://app.revenuecat.com/settings/support) or check our changelog for the latest updates. For further clarification or to discuss how a change might impact your integration, feel free to [contact us](https://app.revenuecat.com/settings/support)!