Skip to content

chore: update release process documentation #695

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.

Sign up for GitHub

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
wants to merge 7 commits into
base: main
Choose a base branch
from
+17 −20
Open

chore: update release process documentation #695

Changes from 3 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
73f7755
chore: update release process documentation
gagik Oct 27, 2025
6130477
chore: format
gagik Oct 27, 2025
22e29ba
chore: add a small note about pre-release
himanshusinghs Oct 27, 2025
6eaa038
chore: add note about renaming vNext
gagik Oct 28, 2025
4df7fba
chore: clarfiy wording
gagik Oct 30, 2025
919fcf9
Merge branch 'main' of github.com:mongodb-js/mongodb-mcp-server into …
gagik Oct 30, 2025
6a8eee6
chore: lint
gagik Oct 30, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 13 additions & 18 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -143,31 +143,26 @@ When adding new tools to the MCP server:

## Release Process

Our release process is automated using GitHub Actions workflows:
To release a new version of the MCP server, follow these steps:

### Version Bumping

1. To create a new version, go to the GitHub repository Actions tab
2. Select the "Version Bump" workflow
3. Click "Run workflow" and choose one of the following options:
1. Ensure there is a Jira _Release_ ticket in the [`MCP` project](https://jira.mongodb.org/projects/MCP) for the new release and move it to _In Progress_.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not opposed to this but curious to hear what's the benefit of having a release ticket as opposed to just looking at the tickets linked to the vNext version?

Copy link
Collaborator Author

@gagik gagik Oct 28, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

biggest benefit is being able to track the release status & who did the release through Jira. Can be useful i.e. for external stakeholders to find the right person to contact or for them to block their release against ours.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair, but in that case, I'd suggest we need to have some automation that would generate the ticket. It sounds a bit tedious to link a bunch of tickets together.

Copy link
Collaborator Author

@gagik gagik Oct 28, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree about automation

It sounds a bit tedious to link a bunch of tickets together.

To clarify, this release ticket is just a regular ticket tied to the release version so no extra linking needed.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I read the "correctly mapped" section from point 2 as we'd need to link them to the release ticket, not that we link the version from the release ticket and then look at the tickets for that version.

2. Verify that the Jira tickets you expect to be released are correctly mapped to the _Release_ ticket. Add any additional required documentation to the release ticket.
3. To create a new version, go to the GitHub repository Actions tab and run the "Prepare Release" workflow with one of the following options:
- `patch` (e.g., 1.0.0 → 1.0.1) for backward-compatible bug fixes
- `minor` (e.g., 1.0.0 → 1.1.0) for backward-compatible new features
- `major` (e.g., 1.0.0 → 2.0.0) for breaking changes
- A specific version number (e.g., `1.2.3`)
4. This creates a pull request with the version change
5. Once approved and merged, the version is updated

### Automatic Publishing
- **Pre-release versions**: To create a pre-release, enter the version suffixed by `-prerelease.{n}` where `n` is the pre-release number (e.g., `1.1.0-prerelease.1`, `1.1.0-prerelease.2`). Pre-releases are release candidates that provide early access to new features before they are promoted to stable.

When a version bump is merged to the main branch:
> **Note**: Stable releases are published under the `latest` tag on NPM and are intended for production use. Pre-release versions are published under the `prerelease` tag and serve as release candidates for early access and feedback before being released as stable versions.

1. The "Publish" workflow automatically runs
2. It checks if the version already exists as a git tag
3. If the version is new, it:
- Builds the package
- Publishes to NPM
- Creates a git tag for the version
- Creates a GitHub release with auto-generated release notes
4. This creates a pull request with the version change.
5. Merge this pull request if all looks correct. This will trigger the "Publish" workflow which will publish it to **NPM**, **Docker** and the **MCP Registry**.
6. Verify that the new version is published correctly by checking:
- NPM: https://www.npmjs.com/package/mongodb-mcp-server
- Docker: https://hub.docker.com/r/mongodb/mongodb-mcp-server
- MCP Registry: `curl "https://registry.modelcontextprotocol.io/v0.1/servers/io.github.mongodb-js%2Fmongodb-mcp-server/versions/latest"`
7. Close the Jira ticket for the release and post an update in the `#mongodb-mcp` Slack channel.

### Code Quality

Expand Down
Loading