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

Added breaking change definition #630

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
44 changes: 44 additions & 0 deletions docs/revenuecat-support/breaking-changes.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
---
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)](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?

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.
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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also I got into hot water when I mentioned the changelog to Outlier and he said "what changelog" and I didn't have a great answer for him. We have release notes but it doesn't include all API changes, neither does the community or email newsletter. Should we just remove "check our changelog"?


For further clarification or to discuss how a change might impact your integration, feel free to contact us!
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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)!


1 change: 1 addition & 0 deletions sidebars.js
Original file line number Diff line number Diff line change
Expand Up @@ -511,6 +511,7 @@ const supportCategory = Category({
items: [
Page({ slug: "general-troubleshooting" }),
Page({ slug: "support-first-steps" }),
Page({ slug: "breaking-changes" }),
],
});

Expand Down