-
Notifications
You must be signed in to change notification settings - Fork 204
feat: implement server versioning approach with semantic versioning support #296
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
domdomegg
wants to merge
5
commits into
main
Choose a base branch
from
claude/issue-158-20250821-2216
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+501
−73
Open
Changes from 2 commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
b4109ed
feat: implement server versioning approach with semantic versioning s…
claude[bot] dcd1fbd
refactor: move version ordering logic from database to service layer
claude[bot] 4eb1635
Address comments
domdomegg 15574c9
fix: clarify version ordering rules for registry clients
domdomegg 96058de
Merge main branch and migrate to PostgreSQL
domdomegg File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -138,4 +138,4 @@ func DeployMongoDB(ctx *pulumi.Context, cluster *providers.ProviderInfo, environ | |
} | ||
|
||
return nil | ||
} | ||
} |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,137 @@ | ||
# Server Versioning Guide | ||
|
||
This document describes the versioning approach for MCP servers published to the registry. | ||
|
||
## Overview | ||
|
||
The MCP Registry supports flexible versioning while encouraging semantic versioning best practices. The registry attempts to parse versions as semantic versions for ordering and comparison, but falls back gracefully for non-semantic versions. | ||
|
||
## Version Requirements | ||
|
||
1. **Version String**: `version` MUST be a string up to 255 characters | ||
2. **Uniqueness**: Each version for a given server name must be unique | ||
3. **Immutability**: Once published, version metadata cannot be changed | ||
|
||
## Best Practices | ||
|
||
### 1. Use Semantic Versioning | ||
Server authors SHOULD use [semantic versions](https://semver.org/) following the `MAJOR.MINOR.PATCH` format: | ||
|
||
```json | ||
{ | ||
"version_detail": { | ||
"version": "1.2.3" | ||
} | ||
} | ||
``` | ||
|
||
### 2. Align with Package Versions | ||
Server authors SHOULD use versions aligned with their underlying packages to reduce confusion: | ||
|
||
```json | ||
{ | ||
"version_detail": { | ||
"version": "1.2.3" | ||
}, | ||
"packages": [{ | ||
"registry_name": "npm", | ||
"name": "@myorg/my-server", | ||
"version": "1.2.3" | ||
}] | ||
} | ||
``` | ||
|
||
### 3. Multiple Registry Versions | ||
If server authors expect to have multiple registry versions for the same package version, they SHOULD follow the semantic version spec using the prerelease label: | ||
|
||
```json | ||
{ | ||
"version_detail": { | ||
"version": "1.2.3-1" | ||
}, | ||
"packages": [{ | ||
"registry_name": "npm", | ||
"name": "@myorg/my-server", | ||
"version": "1.2.3" | ||
}] | ||
} | ||
``` | ||
|
||
**Note**: According to semantic versioning, `1.2.3-1` is considered lower than `1.2.3`, so if you expect to need a `1.2.3-1`, you should publish that before `1.2.3`. | ||
|
||
## Version Ordering and "Latest" Determination | ||
|
||
### For Semantic Versions | ||
The registry attempts to parse versions as semantic versions. If successful, it uses semantic version comparison rules to determine: | ||
- Version ordering in lists | ||
- Which version is marked as `is_latest` | ||
|
||
### For Non-Semantic Versions | ||
If version parsing as semantic version fails: | ||
- The registry will always mark the version as latest (overriding any previous version) | ||
- Clients should fall back to using publish timestamp for ordering | ||
|
||
### Mixed Scenarios | ||
When comparing versions where one is semantic and one is not: | ||
- The semantic version is always considered higher | ||
- This ensures semantic versions take precedence in ordering | ||
domdomegg marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
## Implementation Details | ||
|
||
### Registry Behavior | ||
1. **Validation**: Versions are validated for uniqueness within a server name | ||
2. **Parsing**: The registry attempts to parse each version as semantic version | ||
3. **Comparison**: Uses semantic version rules when possible, falls back to timestamp | ||
4. **Latest Flag**: The `is_latest` field is set based on the comparison results | ||
|
||
### Client Recommendations | ||
Registry clients SHOULD: | ||
1. Attempt to interpret versions as semantic versions when possible | ||
2. Use the following ordering rules: | ||
- If both versions are valid semver: use semver comparison | ||
- If neither are valid semver: use publish timestamp | ||
- If one is semver and one is not: semver version is considered higher | ||
|
||
## Examples | ||
|
||
### Valid Semantic Versions | ||
```json | ||
domdomegg marked this conversation as resolved.
Show resolved
Hide resolved
|
||
"1.0.0" // Basic semantic version | ||
"2.1.3-alpha" // Prerelease version | ||
"1.0.0-beta.1" // Prerelease with numeric suffix | ||
"3.0.0-rc.2" // Release candidate | ||
``` | ||
|
||
### Non-Semantic Versions (Allowed) | ||
```json | ||
domdomegg marked this conversation as resolved.
Show resolved
Hide resolved
|
||
"v1.0" // Version with prefix | ||
"2021.03.15" // Date-based versioning | ||
"snapshot" // Development snapshots | ||
"latest" // Custom versioning scheme | ||
``` | ||
|
||
### Alignment Examples | ||
```json | ||
{ | ||
"version_detail": { | ||
"version": "1.2.3-gke.1" | ||
domdomegg marked this conversation as resolved.
Show resolved
Hide resolved
|
||
}, | ||
"packages": [{ | ||
"registry_name": "npm", | ||
"name": "@myorg/k8s-server", | ||
"version": "1.2.3" | ||
}] | ||
} | ||
``` | ||
|
||
## Migration Path | ||
|
||
Existing servers with non-semantic versions will continue to work without changes. However, to benefit from proper version ordering, server maintainers are encouraged to: | ||
|
||
1. Adopt semantic versioning for new releases | ||
2. Consider the ordering implications when transitioning from non-semantic to semantic versions | ||
3. Use prerelease labels for registry-specific versioning needs | ||
|
||
## Future Considerations | ||
|
||
This versioning approach is designed to be compatible with potential future changes to the MCP specification's `Implementation.version` field. Any SHOULD requirements introduced here may be proposed as updates to the specification through the SEP (Specification Enhancement Proposal) process. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels reasonable in isolation. but actually means that
version
's total ordering is inconsistent withis_latest
, for packages with a mix of versions.Not sure what is best to do here. Maybe this is fine. Maybe we should only update is_latest if it's now the latest in the total ordering spec below, idk.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this behavior is necessary because the publisher does not indicate whether they are actually using semantic versioning. For example, if we said "semantic versions always take precedence", and a publisher is using non-semantic version numbers that sometimes appear to be semantic, then they are going to have a bad time. 😆
Unfortunately, as you noted, this means there is no natural sort order. Instead, we have to maintain an insertion order based on this logic.