Skip to content

Commit df8878c

Browse files
felixweinbergerfelixweinberger
authored
Merge branch 'v1.x' into fweinberger/v1x-docs
2 parents 443635f + 2084a22 commit df8878c

4 files changed

Lines changed: 101 additions & 0 deletions

File tree

‎.github/dependabot.yml‎

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
version: 2
2+
updates:
3+
- package-ecosystem: 'github-actions'
4+
directory: '/'
5+
schedule:
6+
interval: monthly
7+
groups:
8+
github-actions:
9+
patterns:
10+
- '*'

‎DEPENDENCY_POLICY.md‎

Lines changed: 29 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
1+
# Dependency Policy
2+
3+
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.
4+
5+
## Update Triggers
6+
7+
Dependencies are updated when:
8+
9+
- A **security vulnerability** is disclosed (via GitHub security alerts).
10+
- A bug in a dependency directly affects the SDK.
11+
- A new dependency feature is needed for SDK development.
12+
- A dependency drops support for a Node.js version the SDK still targets.
13+
14+
Routine version bumps without a clear motivation are avoided to minimize churn for downstream consumers.
15+
16+
## What We Don't Do
17+
18+
The SDK does not run scheduled version bumps for npm dependencies. Updating a dependency can force downstream consumers to adopt that update transitively, which can be disruptive for projects with strict dependency policies.
19+
20+
Dependencies are only updated when there is a concrete reason, not simply because a newer version is available.
21+
22+
## Automated Tooling
23+
24+
- **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.
25+
- **GitHub Actions versions** are kept up to date via Dependabot on a monthly schedule (see `.github/dependabot.yml`).
26+
27+
## Pinning and Ranges
28+
29+
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‎

Lines changed: 22 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,22 @@
1+
# Roadmap
2+
3+
## Spec Implementation Tracking
4+
5+
The SDK tracks implementation of MCP spec components via GitHub Projects, with a dedicated project board for each spec revision. For example, see the [2025-11-25 spec revision board](https://github.com/orgs/modelcontextprotocol/projects/26).
6+
7+
## Current Focus Areas
8+
9+
### Next Spec Revision
10+
11+
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.
12+
13+
The SDK has historically implemented spec changes promptly as they are finalized, with dedicated project boards tracking component-level progress for each revision.
14+
15+
### v2
16+
17+
A major version of the SDK is in active development, tracked via [GitHub Project](https://github.com/orgs/modelcontextprotocol/projects/31). Target milestones:
18+
19+
- **Alpha**: ~mid-March 2026
20+
- **Beta**: ~May 2026
21+
22+
The v2 release is planned to align with the next spec release, expected around mid-2026.

‎VERSIONING.md‎

Lines changed: 40 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,40 @@
1+
# Versioning Policy
2+
3+
The MCP TypeScript SDK (`@modelcontextprotocol/sdk`) follows [Semantic Versioning 2.0.0](https://semver.org/).
4+
5+
## Version Format
6+
7+
`MAJOR.MINOR.PATCH`
8+
9+
- **MAJOR**: Incremented for breaking changes (see below).
10+
- **MINOR**: Incremented for new features that are backward-compatible.
11+
- **PATCH**: Incremented for backward-compatible bug fixes.
12+
13+
## What Constitutes a Breaking Change
14+
15+
The following changes are considered breaking and require a major version bump:
16+
17+
- Removing or renaming a public API export (class, function, type, or constant).
18+
- Changing the signature of a public function or method in a way that breaks existing callers (removing parameters, changing required/optional status, changing types).
19+
- Removing or renaming a public type or interface field.
20+
- Changing the behavior of an existing API in a way that breaks documented contracts.
21+
- Dropping support for a Node.js LTS version.
22+
- Removing support for a transport type.
23+
- Changes to the MCP protocol version that require client/server code changes.
24+
25+
The following are **not** considered breaking:
26+
27+
- Adding new optional parameters to existing functions.
28+
- Adding new exports, types, or interfaces.
29+
- Adding new optional fields to existing types.
30+
- Bug fixes that correct behavior to match documented intent.
31+
- Internal refactoring that does not affect the public API.
32+
- Adding support for new MCP spec features.
33+
- Changes to dev dependencies or build tooling.
34+
35+
## How Breaking Changes Are Communicated
36+
37+
1. **Changelog**: All breaking changes are documented in the GitHub release notes with migration instructions.
38+
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.
39+
3. **Migration guide**: Major version releases include a migration guide describing what changed and how to update.
40+
4. **PR labels**: Pull requests containing breaking changes are labeled with `breaking change`.

0 commit comments

Comments
 (0)