---
title: "Dropping Platform or Language Version Support"
url: https://develop.sentry.dev/sdk/getting-started/playbooks/sdk-lifecycle/dropping-platform-support/
---

# Dropping Platform or Language Version Support

This document uses key words such as "MUST", "SHOULD", and "MAY" as defined in

<!-- -->

[RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) to indicate requirement levels.

Statuscandidate

Version`1.0.0`[(changelog)](https://develop.sentry.dev/sdk/getting-started/playbooks/sdk-lifecycle/dropping-platform-support.md#changelog)

## [Overview](https://develop.sentry.dev/sdk/getting-started/playbooks/sdk-lifecycle/dropping-platform-support.md#overview)

This playbook guides SDK maintainers through dropping support for a platform or language version in a way that minimizes user disruption. It covers evidence gathering, deprecation announcements, maintenance periods, and eventual removal. By following these steps, users will have clear migration paths and sufficient notice before breaking changes occur.

Related resources:

* [Platform/language version support policy](https://develop.sentry.dev/sdk/getting-started/standards/coordination-maintenance.md#platformlanguage-version-support-policy) — support policy and requirements
* [Breaking change process](https://develop.sentry.dev/sdk/getting-started/standards/api-architecture.md#breaking-and-deprecation) — process for removal in major versions
* [Deprecation lifecycle](https://develop.sentry.dev/sdk/getting-started/standards/api-architecture.md#breaking-and-deprecation) — deprecation timeline
* [Deprecating an SDK](https://develop.sentry.dev/sdk/getting-started/playbooks/sdk-lifecycle/deprecating-an-sdk.md) — when deprecating the entire SDK, not just a platform version

***

## [Steps](https://develop.sentry.dev/sdk/getting-started/playbooks/sdk-lifecycle/dropping-platform-support.md#steps)

#### [1. Open an issue with evidence](https://develop.sentry.dev/sdk/getting-started/playbooks/sdk-lifecycle/dropping-platform-support.md#1-open-an-issue-with-evidence)

Before proposing to drop support, you **MUST** gather and document:

* **Upstream EOL status**: Has the language/platform version reached end of life?
* **Usage data**: What percentage of users are on this version?
* **Maintenance burden**: How much effort does supporting this version cost?

This evidence helps stakeholders make informed decisions about the timeline and impact.

#### [2. Announce deprecation in a minor release](https://develop.sentry.dev/sdk/getting-started/playbooks/sdk-lifecycle/dropping-platform-support.md#2-announce-deprecation-in-a-minor-release)

In the minor release where support is deprecated, you **MUST**:

* Add a changelog entry stating which version will be dropped and when
* Update documentation (README, docs site) to reflect the deprecation
* Keep CI testing against the deprecated version during this period

This ensures users have clear warning before breaking changes occur.

#### [3. Wait at least one full minor release cycle](https://develop.sentry.dev/sdk/getting-started/playbooks/sdk-lifecycle/dropping-platform-support.md#3-wait-at-least-one-full-minor-release-cycle)

You **MUST** wait at least one full minor release cycle after the deprecation announcement. Users need time to see the deprecation and plan their upgrade path.

#### [4. Remove in the next major version](https://develop.sentry.dev/sdk/getting-started/playbooks/sdk-lifecycle/dropping-platform-support.md#4-remove-in-the-next-major-version)

When removing support in a major version, you **MUST**:

* Drop the version from the CI test matrix
* Update documentation (README, docs site) to reflect the removed support
* Include `BREAKING CHANGE:` in the commit footer ([Breaking change process](https://develop.sentry.dev/sdk/getting-started/standards/api-architecture.md#breaking-and-deprecation))

#### [5. Provide migration guidance](https://develop.sentry.dev/sdk/getting-started/playbooks/sdk-lifecycle/dropping-platform-support.md#5-provide-migration-guidance)

You **MUST** provide clear migration guidance in the changelog and documentation:

> Upgrade to \[language/platform] version X.Y or later before upgrading to SDK version N.

This helps users understand the upgrade path and avoid breaking their applications.

## [Referenced Standards](https://develop.sentry.dev/sdk/getting-started/playbooks/sdk-lifecycle/dropping-platform-support.md#referenced-standards)

* [Breaking change process](https://develop.sentry.dev/sdk/getting-started/standards/api-architecture.md#breaking-and-deprecation) — process for removal in major versions
* [Deprecation lifecycle](https://develop.sentry.dev/sdk/getting-started/standards/api-architecture.md#breaking-and-deprecation) — deprecation timeline requirements
* [Platform/language version support policy](https://develop.sentry.dev/sdk/getting-started/standards/coordination-maintenance.md#platformlanguage-version-support-policy) — support policy baseline

***

| Version | Date       | Summary                                                                                                    |
| ------- | ---------- | ---------------------------------------------------------------------------------------------------------- |
| `1.0.0` | 2026-02-23 | Initial playbook — platform/language version deprecation with evidence requirements and migration guidance |