ddd694acdf<!-- Provide a brief summary of your changes --> ## Motivation and Context <!-- Why is this change needed? What problem does it solve? --> The following PR fixes the docs and the image reference for prod since they don't expect to have the v prefix there. ## How Has This Been Tested? <!-- Have you tested this in a real application? Which scenarios were tested? --> ## Breaking Changes <!-- Will users need to update their code or configurations? --> ## Types of changes <!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] Documentation update ## Checklist <!-- Go over all the following points, and put an `x` in all the boxes that apply. --> - [ ] I have read the [MCP Documentation](https://modelcontextprotocol.io) - [ ] My code follows the repository's style guidelines - [ ] New and existing tests pass locally - [ ] I have added appropriate error handling - [ ] I have added or updated documentation as needed ## Additional context <!-- Add any other context, implementation notes, or design decisions --> --------- Signed-off-by: Radoslav Dimitrov <radoslav@stacklok.com>
48 lines
No EOL
2.2 KiB
Markdown
48 lines
No EOL
2.2 KiB
Markdown
# Release Guide
|
||
|
||
## Creating a Release
|
||
|
||
1. **Go to GitHub**: Navigate to https://github.com/modelcontextprotocol/registry/releases
|
||
2. **Click "Draft a new release"**
|
||
3. **Choose a tag**: Click "Choose a tag" and type a new semantic version that follows the last one available (e.g., `v1.0.0`)
|
||
5. **Generate notes**: Click "Generate release notes" to auto-populate the name and description
|
||
6. **Publish**: Click "Publish release"
|
||
|
||
The release workflow will automatically:
|
||
- Build binaries for 6 platforms (Linux, macOS, Windows × amd64, arm64)
|
||
- Create and push Docker images with `:latest` and `:X.Y.Z` tags (note: no 'v' prefix)
|
||
- Attach all artifacts to the GitHub release
|
||
- Generate checksums and signatures
|
||
|
||
## After Release
|
||
|
||
- Docker images will be available at:
|
||
- `ghcr.io/modelcontextprotocol/registry:latest` - Latest stable release
|
||
- `ghcr.io/modelcontextprotocol/registry:X.Y.Z` - Specific release version (note: no 'v' prefix)
|
||
- Binaries can be downloaded from the GitHub release page
|
||
|
||
**Note:** Releases do not automatically deploy to production. To deploy a release to production:
|
||
|
||
1. Update `mcp-registry:imageTag` in `deploy/Pulumi.gcpProd.yaml` to the desired version (e.g., `1.2.3` - note: no 'v' prefix)
|
||
2. Commit and push the change to the `main` branch
|
||
3. The [deploy-production.yml](../../../.github/workflows/deploy-production.yml) workflow will automatically trigger and deploy the specified version
|
||
|
||
See the [deployment documentation](../../../deploy/README.md) for more details.
|
||
|
||
## Docker Image Tags
|
||
|
||
The registry publishes different Docker image tags for different use cases:
|
||
|
||
- **`:latest`** - Latest stable release (updated only on releases)
|
||
- **`:X.Y.Z`** - Specific release versions (e.g., `:1.0.0` - note: no 'v' prefix)
|
||
- **`:main`** - Rolling tag updated on every push to main branch (continuous deployment)
|
||
- **`:main-YYYYMMDD-sha`** - Specific development builds from main branch
|
||
|
||
**Note:** Git release tags include the 'v' prefix (e.g., `v1.0.0`), but Docker image tags follow the standard Docker convention and do not include the 'v' prefix (e.g., `1.0.0`).
|
||
|
||
## Versioning
|
||
|
||
We use semantic versioning (SemVer):
|
||
- `v1.0.0` - Major release with breaking changes
|
||
- `v1.1.0` - Minor release with new features
|
||
- `v1.0.1` - Patch release with bug fixes |