---
title: "Coordination and Maintenance"
url: https://develop.sentry.dev/sdk/getting-started/standards/coordination-maintenance/
---

# Coordination and Maintenance

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.

Statusstable

Version`1.0.0`[(changelog)](https://develop.sentry.dev/sdk/getting-started/standards/coordination-maintenance.md#changelog)

These standards cover how SDK teams coordinate across repositories, respond to users, and keep things running after code ships. The common thread: don't let things fall through the cracks.

## [Cross-SDK changes](https://develop.sentry.dev/sdk/getting-started/standards/coordination-maintenance.md#cross-sdk-changes)

Stablespecified since

<!-- -->

1.0.0

When a change affects multiple SDKs, follow this sequence:

1. **Proposal** — RFC or issue describing the change
2. **Cross-SDK review** — at least 1 week for feedback
3. **Sequencing decision** — agree on rollout order
4. **Tracking** — set up as a Linear initiative
5. **Communication** — coordinate announcements

See [Aligning Cross-SDK Changes](https://develop.sentry.dev/sdk/getting-started/playbooks/coordination/aligning-cross-sdk-changes.md) for the step-by-step playbook and [Managing Linear Projects](https://develop.sentry.dev/sdk/getting-started/playbooks/coordination/managing-linear-projects.md) for running per-SDK projects.

***

## [Issue triage](https://develop.sentry.dev/sdk/getting-started/standards/coordination-maintenance.md#issue-triage)

Stablespecified since

<!-- -->

1.0.0

All user-reported issues **MUST** get a substantive first response within 2 business days. "Substantive" means acknowledging the problem, asking for reproduction steps, confirming it as a known issue, or explaining the resolution — not just a thumbs-up emoji.

Issues on GitHub and Linear are automatically labeled to track where action is needed:

* **`Waiting for: Product Owner`** — the maintainer **MUST** respond within 2 business days. The SLA restarts each time this label becomes active.
* **`Waiting for: Community`** — the maintainer has responded and is waiting for a reply or reproduction from the reporter. No SLA while this label is active.

Labels are managed automatically and reset on state transitions. Both are removed when the issue is closed.

See the [Triaging playbook](https://develop.sentry.dev/sdk/getting-started/playbooks/coordination/triaging.md) for the full workflow.

***

## [Platform and language version support](https://develop.sentry.dev/sdk/getting-started/standards/coordination-maintenance.md#platform-and-language-version-support)

Stablespecified since

<!-- -->

1.0.0

Supported versions should be documented in the README and docs. Dropping support for a platform or language version is a breaking change — it follows the [breaking change and deprecation process](https://develop.sentry.dev/sdk/getting-started/standards/api-architecture.md#breaking-and-deprecation) and needs evidence: usage data, upstream EOL status, or maintenance burden. Announce it at least one minor release before the major that drops support.

Each SDK owns its version matrix. CI should test all supported versions.

***

## [Post-release monitoring and regression handling](https://develop.sentry.dev/sdk/getting-started/standards/coordination-maintenance.md#post-release-monitoring-and-regression-handling)

Stablespecified since

<!-- -->

1.0.0

### [Monitoring](https://develop.sentry.dev/sdk/getting-started/standards/coordination-maintenance.md#monitoring)

After each release, watch for problems:

* Monitor SDK crash detection
* Verify dogfooding picks up the new version
* Watch the issue tracker for 48 hours
* Patch critical regressions within 48 hours

### [Handling regressions](https://develop.sentry.dev/sdk/getting-started/standards/coordination-maintenance.md#handling-regressions)

Every SDK **MUST** have a documented regression handling plan covering:

* How to yank or unpublish a release
* How to cut a revert release
* Who has permissions — at least two people per SDK must be able to publish and yank
* A communication template for notifying users

An annual regression handling drill is recommended. See [Setting up release infrastructure](https://develop.sentry.dev/sdk/getting-started/playbooks/setup/setting-up-release-infrastructure.md) for initial setup.

***

## [Documenting decisions](https://develop.sentry.dev/sdk/getting-started/standards/coordination-maintenance.md#documenting-decisions)

Stablespecified since

<!-- -->

1.0.0

Decisions should be traceable. Before making one, reference or create a Linear or GitHub issue to anchor the discussion. If a meeting happens, enable notes or recording — key decisions **MUST** be summarized and linked to the issue afterward.

Slack is fine for coordination, but outcomes **MUST** be moved to the system of record (Linear, GitHub, or Develop Docs) before the thread is considered closed. Update the issue immediately, link supporting docs, and assign action items with owners.

***

## [Changelog](https://develop.sentry.dev/sdk/getting-started/standards/coordination-maintenance.md#changelog)

| Version | Date       | Summary                                       |
| ------- | ---------- | --------------------------------------------- |
| `1.0.0` | 2026-02-19 | Initial Coordination and Maintenance standard |