URL: https://gofastmcp.com/development/releases
Title: Releases - FastMCP

Documentation Index
Fetch the complete documentation index at:
/llms.txt
Use this file to discover all available pages before exploring further.
Skip to main content
Meet
Prefect Horizon
, the enterprise MCP gateway built by the team behind FastMCP
FastMCP
home page
v3
Prefect Horizon
PrefectHQ/fastmcp
25,596
PrefectHQ/fastmcp
25,596
Search...
Navigation
Development
Releases
Search the docs...
Ctrl
K
Documentation
Get Started
Welcome!
Installation
Quickstart
Servers
Overview
Core Components
Working with Tools
MCP Providers
Interactivity
Extensibility
Auth
Deployment
Apps
Overview
Quickstart
NEW
FastMCPApp
NEW
Interactive Tools
NEW
Generative UI
NEW
Custom HTML
Reference
Clients
Overview
Client-Only Package
Transports
fastmcp-remote
Operations
UPDATED
Authentication
UPDATED
Integrations
Auth
Web Frameworks
AI Assistants
AI SDKs
MCP.json
More
Settings
CLI
Upgrading
Development
Contributing
Tests
Releases
Contrib Modules
What's New
FAQ
On this page
Versioning Policy
Semantic Versioning
Breaking Changes
Production Use
Creating Releases
Release Cadence
Development
Releases
Copy page
FastMCP versioning and release process
Copy page
FastMCP releases frequently to deliver features quickly in the rapidly evolving MCP ecosystem. We use semantic versioning pragmatically - the Model Context Protocol is young, patterns are still emerging, and waiting for perfect stability would mean missing opportunities to empower developers with better tools.
​
Versioning Policy
​
Semantic Versioning
Major (x.0.0)
: Complete API redesigns
Major versions represent fundamental shifts. FastMCP 2.x is entirely different from 1.x in both implementation and design philosophy.
Minor (2.x.0)
: New features and evolution
Unlike traditional semantic versioning, minor versions
may
include
breaking changes
when necessary for the ecosystem’s evolution. This flexibility is essential in a young ecosystem where perfect backwards compatibility would prevent important improvements.
FastMCP always targets the most current MCP Protocol version. Breaking changes in the MCP spec or MCP SDK automatically flow through to FastMCP - we prioritize staying current with the latest features and conventions over maintaining compatibility with older protocol versions.
Patch (2.0.x)
: Bug fixes and refinements
Patch versions contain only bug fixes without breaking changes. These are safe updates you can apply with confidence.
​
Breaking Changes
We permit breaking changes in minor versions because the MCP ecosystem is rapidly evolving. Refusing to break problematic APIs would accumulate design debt that eventually makes the framework unusable. Each breaking change represents a deliberate decision to keep FastMCP aligned with the ecosystem’s evolution.
When breaking changes occur:
They only happen in minor versions (e.g., 2.3.x to 2.4.0)
Release notes explain what changed and how to migrate
We provide deprecation warnings at least 1 minor version in advance when possible
Changes must substantially benefit users to justify disruption
The public API is what’s covered by our compatibility guarantees - these are the parts of FastMCP you can rely on to remain stable within a minor version. The public API consists of:
FastMCP
server class,
Client
class, and FastMCP
Context
Core MCP components:
Tool
,
Prompt
,
Resource
,
ResourceTemplate
, and transports
Their public methods and documented behaviors
Everything else (utilities, private methods, internal modules) may change without notice. This boundary lets us refactor internals and improve implementation details without breaking your code. For production stability, pin to specific versions.
The
fastmcp.server.auth
module was introduced in 2.12.0 and is exempted from this policy temporarily, meaning it is
expected
to have breaking changes even on patch versions. This is because auth is a rapidly evolving part of the MCP spec and it would be dangerous to be beholden to old decisions. Please pin your FastMCP version if using authentication in production.
We expect this exemption to last through at least the 2.12.x and 2.13.x release series.
​
Production Use
Pin to exact versions:
fastmcp==2.11.0 # Good
fastmcp>=2.11.0 # Bad - will install breaking changes
​
Creating Releases
Our release process is intentionally simple:
Create GitHub release with tag
vMAJOR.MINOR.PATCH
(e.g.,
v2.11.0
)
Generate release notes automatically, and curate or add additional editorial information as needed
GitHub releases automatically trigger PyPI deployments
This automation lets maintainers focus on code quality rather than release mechanics.
​
Release Cadence
We follow a feature-driven release cadence rather than a fixed schedule. Minor versions ship approximately every 3-4 weeks when significant functionality is ready.
Patch releases ship promptly for:
Critical bug fixes
Security updates (immediate release)
Regression fixes
This approach means you get improvements as soon as they’re ready rather than waiting for arbitrary release dates.
Tests
Previous
Contrib Modules
Next
Ctrl
+I
discord
github
website
x
Powered by
This documentation is built and hosted on Mintlify, a developer documentation platform
Assistant
Responses are generated using AI and may contain mistakes.
\n\n
\n
\n \n
\n
