name: release-management
description: >
Prepares a MockServer release by recommending the release version from
Semantic Versioning rules and changelog.md, checking release readiness,
and listing the exact Buildkite release parameters. Use when users say
"prepare release", "release version", "run the release pipeline",
"which version should we release", or need to verify changelog and secret
readiness before triggering the release pipeline.
Prepare a MockServer Release
Use this workflow before triggering the mockserver-release Buildkite pipeline.
Required Inputs
Inspect these sources every time:
changelog.md— especially the## [Unreleased]sectionmockserver/pom.xml— current development-SNAPSHOTversion.buildkite/release-pipeline.yml— supported release parameters and automated stepsdocs/operations/release-process.md— operator-facing release guidance- Git tags matching
mockserver-X.Y.Z— latest numeric release is the authoritativeold-version
If AWS access is available, also verify the required secrets exist and contain the expected keys without printing secret values.
Version Recommendation Rules
Recommend the next release from the latest numeric mockserver-X.Y.Z tag, not from the current -SNAPSHOT alone.
Apply these rules in order:
- Major release — if any unreleased changelog bullet is explicitly marked
BREAKING: - Minor release — if there are meaningful bullets under
AddedorChangedand noBREAKING:markers - Patch release — if there are only meaningful bullets under
Fixed - Block release — if the unreleased changelog is empty, vague, or not ready to publish
Definitions:
- A "meaningful bullet" is a non-empty
- ...entry BREAKING:should appear at the start of an unreleased bullet when a major version bump is intended
Derived values:
release-version: recommended SemVer releasenext-version:release-versionpatch increment plus-SNAPSHOTold-version: latest numericmockserver-X.Y.Ztagrelease-type:fullunless the user explicitly wants a partial reruncreate-versioned-site:yesfor major or minor releases,nofor patch releases
Readiness Checks
Validate each of these before declaring the release ready:
changelog.mdhas meaningful unreleased bulletschangelog.mddoes not already contain a section for the proposedrelease-versionmockserver/pom.xmlis currently on anX.Y.Z-SNAPSHOTversion- The pipeline supports the required outputs for this release:
- Maven Central core artifacts
mockserver-maven-plugin- Docker Hub and AWS ECR Public images
mockserver-nodemockserver-client- Helm
- Javadoc
- SwaggerHub / OpenAPI
- website
- JSON Schema
- PyPI
- RubyGems
- GitHub Release
- Required secrets are present:
mockserver-build/sonatypemockserver-build/dockerhubmockserver-build/pypimockserver-build/rubygemsmockserver-release/gpg-keymockserver-release/github-tokenmockserver-release/totp-seedmockserver-release/npm-tokenmockserver-release/swaggerhubmockserver-release/website-role
Output Format
Return a concise release-preparation report with these sections:
Recommendation
release-versionnext-versionold-versionrelease-typecreate-versioned-site
Rationale
- Explain why the bump is major, minor, or patch
- Cite the relevant changelog bullets and release tag comparison
Readiness
changelog: pass/fail with reasonversion state: pass/fail with current snapshot versionsecrets: pass/fail with missing items, if anypipeline coverage: pass/fail with any remaining gaps
Manual Follow-up
Steps outside — or not guaranteed by — the automated pipeline:
- Homebrew — always manual, after the GitHub Release is published:
brew bump-formula-pr --strict --version=<release-version> mockserver - SwaggerHub — the
swaggerhubpipeline step issoft_fail: true, so a failure never blocks the release. Publishing via the SwaggerHub Registry API needs account / API-plan access the pipeline cannot guarantee — the write endpoint can return403/404even with a valid key on an account without it. The step is kept in the pipeline so it publishes automatically if that access is ever in place; but if it soft-fails, upload the spec manually: open https://app.swaggerhub.com, go to thejamesdbloom/mock-server-openapiAPI, and add the new version frommockserver/mockserver-core/src/main/resources/org/mockserver/openapi/mock-server-openapi-embedded-model.yaml(the web UI needs no API key). This may become fully automatic if SwaggerHub changes that API behaviour.
Monitor & Verify
Always include this section verbatim so the operator can watch the release land. Substitute the chosen release-version into the URLs:
- Sonatype Central Portal (live deployment status): https://central.sonatype.com/publishing/deployments
- Central Portal artifact view: https://central.sonatype.com/artifact/org.mock-server/mockserver-netty/
- Live at Maven Central (canonical "released" signal — returns 200 once synced): https://repo1.maven.org/maven2/org/mock-server/mockserver-netty/
/ - Maven Central search (browse all org.mock-server artifacts): https://central.sonatype.com/search?namespace=org.mock-server&sort=published
- Docker Hub tags: https://hub.docker.com/r/mockserver/mockserver/tags
- npm — mockserver-node: https://www.npmjs.com/package/mockserver-node
- npm — mockserver-client-node: https://www.npmjs.com/package/mockserver-client-node
- PyPI: https://pypi.org/project/mockserver-client/
- RubyGems: https://rubygems.org/gems/mockserver-client
- GitHub Releases: https://github.com/mock-server/mockserver/releases
- Buildkite pipeline: https://buildkite.com/mockserver/mockserver-release
Notes
- Prefer explicit evidence from the repo over assumptions
- If the changelog suggests a major bump but no
BREAKING:marker exists, call that out and ask the user whether the release should be treated as breaking before finalising the recommendation - If the user asks to run a partial rerun, keep
release-versionandold-versionconsistent with the already-published release and explain which downstream steps will be skipped