Changelog & Releases
Relevant source files
The following files were used as context for generating this wiki page:
The Changelog & Releases system in the Anthropic Go SDK is an automated pipeline designed to manage versioning, document changes, and distribute package updates. The system leverages release-please for automated Pull Request generation and version bumping, ensuring that every modification to the codebase is tracked and categorized according to Conventional Commits.
The release process is integrated with the project's build system and repository metadata, maintaining synchronization between the source code, documentation in the README.md, and internal version tracking.
Release Automation and Configuration
The project utilizes a release-please configuration to manage the lifecycle of a release. This automation identifies changes based on commit types and aggregates them into a structured changelog.
Versioning Strategy
The SDK follows a "prerelease" versioning strategy where the prerelease flag is set to true. The system is configured to bump minor versions for pre-major releases and includes a "v" prefix in Git tags (e.g., v1.30.0).
Sources: release-please-config.json:7-12
Automated Release PRs
When changes are merged into the main branch, the automation creates an "Automated Release PR" with the title pattern release: ${version}. This PR updates several specific files to reflect the new version number.
Sources: release-please-config.json:13-14, release-please-config.json:52-56
Categorization of Changes
Changes are categorized in the changelog based on their commit type. The following table illustrates how different contribution types are mapped to changelog sections:
| Commit Type | Changelog Section | Visibility |
|---|---|---|
feat | Features | Visible |
fix | Bug Fixes | Visible |
perf | Performance Improvements | Visible |
revert | Reverts | Visible |
chore | Chores | Visible |
docs | Documentation | Visible |
style | Styles | Visible |
refactor | Refactors | Visible |
test | Tests | Hidden |
ci | Continuous Integration | Hidden |
build | Build System | Visible |
Sources: release-please-config.json:15-50
Release Workflow and Artifacts
The release workflow involves both the generation of version metadata and the physical packaging of the SDK for distribution.
Build and Packaging Flow
The SDK includes utility scripts to package source files into a distributable format. This process filters for relevant Go files while excluding build artifacts like the dist directory.
The diagram shows the logic used to bundle the SDK source code for release.
Sources: scripts/utils/upload-artifact.sh:6-50
External Version References
The current version of the SDK is prominently displayed in the README.md and used for installation instructions. This allows users to explicitly add the dependency using the latest version tag.
Sources: README.md:21-27
Development and Contributions
The release process is closely tied to the development environment and contribution guidelines. Contributors are expected to follow specific formatting and testing procedures before code is considered for a release.
Contribution Prerequisites
- Environment Setup: Developers must run
./scripts/bootstrapand./scripts/lintto ensure the environment is ready and code meets quality standards. - Code Generation: Most of the SDK is generated. Manual modifications in
lib/andexamples/are persisted, but changes elsewhere might be overwritten by the generator. - Formatting: The project enforces standard Go formatting via
./scripts/format.
Sources: CONTRIBUTING.md:7-16, CONTRIBUTING.md:55-59
SDK Metadata in Requests
Released versions of the SDK identify themselves in API requests via the User-Agent and X-Stainless-Package-Version headers. This allows the Anthropic API to track which version of the Go SDK is making a specific call.
Sources: toolrunner/testdata/cassettes/tool_runner_next_streaming.yaml:16-24
Summary
The "Changelog & Releases" system ensures the Anthropic Go SDK maintains a high level of transparency and reliability. By automating versioning and changelog generation through release-please-config.json and providing clear contribution paths in CONTRIBUTING.md, the project maintains a consistent release cadence that is easily consumable by developers via standard Go toolchains.