Release process
Find a release
Published versions and release notes are listed on GitHub Releases. The changelog summarizes changes to the library.
Install the latest released core package from an existing Go module:
go get github.com/ZihxS/RespKit/respTo install a specific release, append its tag to the package path with @. Check the selected version's module manifest for its Go requirements.
Optional integrations are separate Go modules with their own dependencies and Go requirements. A root release tag does not version a nested module; nested modules require tags that include their directory path.
Requirements before publication
Submit release changes through a pull request and satisfy every check required by the main branch. The branch must be up to date before merging, and the same requirements apply to maintainers.
The release checks cover:
| Area | What to verify |
|---|---|
| Public API | Existing helpers work without configuration, and application data keys remain unchanged |
| Error safety | Raw internal errors stay hidden by default, and public codes and statuses remain stable |
| Core checks | Tests, go vet, race detection, and the combined statement-coverage requirement pass |
| Platform support | Core tests execute on the platforms configured in CI |
| HTTP frameworks | Runtime tests pass against the upstream versions selected by the integration suite |
| Optional integrations | Mapper tests pass in their separate modules |
| Documentation | Examples, internal links, changelog entries, and the static site build are current |
| Repository security | Private reporting, Dependabot alerts, and main branch protections are enabled |
Use the CI workflow and GitHub Actions to inspect the current checks and their results. The compatibility guide explains the scope of those results.
Review open Dependabot alerts before publication and resolve or document any that affect the release. Report suspected vulnerabilities through the private channel described in the security guide.
Publish a release
- Update the changelog and relevant documentation. Preserve the public API or describe breaking changes clearly.
- Run the checks in the testing guide. Keep raw internal errors hidden and preserve the zero-configuration response helpers.
- Submit changes through a pull request and merge only after every required check passes.
- Confirm the exact main commit to release has a successful quality-gates run. Review open Dependabot alerts and resolve or document any that affect the release.
- Confirm private reporting, Dependabot alerts, and main branch protection remain enabled.
- Create the version tag and GitHub release from that verified commit. Include installation instructions, changes, compatibility information, and links to verification results.
- Verify the published tag resolves to the intended commit, then update the release links in the documentation.
Keep published version tags unchanged. Publish a new version when a released package needs a correction.