Commit graph registry/.goreleaser.yaml
Author SHA1 Message Date
adam jones
7ff61e2d6e
Use 'latest' tag for mcp-publisher downloads (#610)
## Summary

This PR removes version numbers from release asset names and updates
documentation to use GitHub's `latest` tag for mcp-publisher downloads.

## Changes

1. **Updated `.goreleaser.yaml`**: Removed `{{ .Version }}` from asset
name templates
   - Changed from: `mcp-publisher_{{ .Version }}_{{ .Os }}_{{ .Arch }}`
   - Changed to: `mcp-publisher_{{ .Os }}_{{ .Arch }}`

2. **Updated documentation**: Changed all download URLs to use `latest`
tag instead of version-pinned URLs
   - `docs/guides/publishing/publish-server.md`
   - `docs/guides/publishing/github-actions.md`

## Benefits

- Documentation stays automatically up-to-date without manual changes or
workflows
- Users always get the latest version by default
- Version pinning still possible using specific tags (e.g.,
`https://github.com/modelcontextprotocol/registry/releases/download/v1.2.3/mcp-publisher_darwin_amd64.tar.gz`)
- Simpler maintenance and better user experience

## Notes

The new asset naming will take effect with the next release. After that,
users can immediately start using the `latest` tag.

Fixes #607
2025-10-04 00:00:27 +03:00
Radoslav Dimitrov
959cdff9f7
Split registry and mcp-publisher into seperate release assets (#377)
<!-- Provide a brief summary of your changes -->

## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
The following PR splits the release assets into 2 - one for the registry
and one for the mcp-publisher CLI.

## How Has This Been Tested?
<!-- Have you tested this in a real application? Which scenarios were
tested? -->
Locally

## Breaking Changes
<!-- Will users need to update their code or configurations? -->
No

## 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>
2025-09-08 14:06:45 -07:00
Radoslav Dimitrov
16790150e9
Introduce Goreleaser (#366)
<!-- Provide a brief summary of your changes -->

## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
The following PR introduces Goreleaser for the releases of the registry
server and the publisher CLI.

**Details:**
- Builds registry and publisher binaries for Linux, macOS, and Windows
(amd64 + arm64)
- Leverage GitHub's release process by creating releases directly from
GitHub's interface
- Added .goreleaser.yaml configuration
- New .github/workflows/release.yml workflow triggered by GitHub
releases
- Updated Docker tagging in deploy workflow (:latest and :semver(the
tag) for releases, :main-YYYYMMDD-sha for testing/development)
- Consolidated version handling in main.go files
- Added release documentation

## How Has This Been Tested?
<!-- Have you tested this in a real application? Which scenarios were
tested? -->

Locally (but we have to test it by creating a release, i.e. v0.0.1 once
this gets merged)

## Breaking Changes
<!-- Will users need to update their code or configurations? -->
Yes, the notion of `latest` for the container image is now different

## 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)
- [x] 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
-->
Related to #358

---------

Signed-off-by: Radoslav Dimitrov <radoslav@stacklok.com>
2025-09-08 11:03:39 -07:00