docs: add governance documentation for SEP-1730

Add documentation required for SEP-1730 tier compliance:

- DEPENDENCY_POLICY.md: conservative dependency update policy — deps
  are kept stable unless there is a concrete reason to update. No
  scheduled npm version bumps.

- VERSIONING.md: SemVer policy covering version format, breaking vs
  non-breaking change definitions, and communication practices.

- ROADMAP.md: spec implementation tracking via GitHub Projects, next
  spec revision focus areas (extensions, stateless transports), and
  v2 development timeline.

- .github/dependabot.yml: monthly GitHub Actions updates (grouped).

Author: felixweinberger

.github/dependabot.yml

@@ -0,0 +1,10 @@
+version: 2
+updates:
+    - package-ecosystem: 'github-actions'
+      directory: '/'
+      schedule:
+          interval: monthly
+      groups:
+          github-actions:
+              patterns:
+                  - '*'

DEPENDENCY_POLICY.md

@@ -0,0 +1,28 @@
+# Dependency Policy
+
+As a library consumed by downstream projects, the MCP TypeScript SDK takes a conservative approach to dependency updates. Dependencies are kept stable unless there is a specific reason to update, such as a security vulnerability, a bug fix, or a need for new functionality.
+
+## Update Triggers
+
+Dependencies are updated when:
+
+- A **security vulnerability** is disclosed (via GitHub security alerts).
+- A bug in a dependency directly affects the SDK.
+- A new dependency feature is needed for SDK development.
+- A dependency drops support for a Node.js version the SDK still targets.
+
+Routine version bumps without a clear motivation are avoided to minimize churn for downstream consumers.
+
+## What We Don't Do
+
+The SDK does not run scheduled version bumps for npm dependencies. As a library, updating a dependency can force downstream consumers to adopt that update transitively — which can be disruptive for projects with strict dependency policies. Dependencies are only updated when there
+is a concrete reason, not simply because a newer version is available.
+
+## Automated Tooling
+
+- **GitHub security updates** are enabled at the repository level and automatically open pull requests for npm packages with known vulnerabilities. This is a GitHub repo setting, separate from the `dependabot.yml` configuration.
+- **GitHub Actions versions** are kept up to date via Dependabot on a monthly schedule (see `.github/dependabot.yml`).
+
+## Pinning and Ranges
+
+Production dependencies use caret ranges (`^`) to allow compatible updates within a major version. Exact versions are pinned only when necessary to work around a specific issue.

ROADMAP.md

@@ -0,0 +1,23 @@
+# Roadmap
+
+## Spec Implementation Tracking
+
+The SDK tracks implementation of MCP spec components via [GitHub Projects](https://github.com/orgs/modelcontextprotocol/projects/26). Each spec revision gets a dedicated project board tracking implementation status of individual components.
+
+## Current Focus Areas
+
+### Next Spec Revision
+
+The next MCP specification revision is being developed in the [protocol repository](https://github.com/modelcontextprotocol/modelcontextprotocol). Key areas expected in the next revision include extensions and stateless transports. Follow the protocol repository for updates on
+spec development.
+
+The SDK has historically implemented spec changes promptly as they are finalized, with dedicated project boards tracking component-level progress for each revision.
+
+### v2
+
+A major version of the SDK is in active development, tracked via [GitHub Project](https://github.com/orgs/modelcontextprotocol/projects/31). Target milestones:
+
+- **Alpha**: ~mid-March 2026
+- **Beta**: ~May 2026
+
+The v2 release is planned to align with the next spec release, expected around mid-2026.

VERSIONING.md

@@ -0,0 +1,40 @@
+# Versioning Policy
+
+The MCP TypeScript SDK (`@modelcontextprotocol/sdk`) follows [Semantic Versioning 2.0.0](https://semver.org/).
+
+## Version Format
+
+`MAJOR.MINOR.PATCH`
+
+- **MAJOR**: Incremented for breaking changes (see below).
+- **MINOR**: Incremented for new features that are backward-compatible.
+- **PATCH**: Incremented for backward-compatible bug fixes.
+
+## What Constitutes a Breaking Change
+
+The following changes are considered breaking and require a major version bump:
+
+- Removing or renaming a public API export (class, function, type, or constant).
+- Changing the signature of a public function or method in a way that breaks existing callers (removing parameters, changing required/optional status, changing types).
+- Removing or renaming a public type or interface field.
+- Changing the behavior of an existing API in a way that breaks documented contracts.
+- Dropping support for a Node.js LTS version.
+- Removing support for a transport type.
+- Changes to the MCP protocol version that require client/server code changes.
+
+The following are **not** considered breaking:
+
+- Adding new optional parameters to existing functions.
+- Adding new exports, types, or interfaces.
+- Adding new optional fields to existing types.
+- Bug fixes that correct behavior to match documented intent.
+- Internal refactoring that does not affect the public API.
+- Adding support for new MCP spec features.
+- Changes to dev dependencies or build tooling.
+
+## How Breaking Changes Are Communicated
+
+1. **Changelog**: All breaking changes are documented in the GitHub release notes with migration instructions.
+2. **Deprecation**: When feasible, APIs are deprecated for at least one minor release before removal using `@deprecated` JSDoc annotations, which surface warnings through TypeScript tooling and editors.
+3. **Migration guide**: Major version releases include a migration guide describing what changed and how to update.
+4. **PR labels**: Pull requests containing breaking changes are labeled with `breaking change`.