1.1. Versioning: Semantic Versioning (SemVer)

To clearly communicate the nature of changes in each release, the A2A Protocol will adhere strictly to Semantic Versioning (SemVer) using a MAJOR.MINOR.PATCH format.

• MAJOR Version (e.g., 2.0.0): Reserved for incompatible, breaking changes to the protocol. Any modification that requires existing agents or SDKs to be updated to maintain interoperability will trigger a MAJOR version increase.
• MINOR Version (e.g., 1.1.0): Used for adding new features or capabilities in a backward-compatible manner. This includes the introduction of new, optional fields or new endpoints. Any change in behavior that SDK developers need to be aware of, but that does not break existing implementations, must be a MINOR release.
• PATCH Version (e.g., 1.0.1): Limited to backward-compatible bug fixes, typo corrections, and clarifications in the specification. Changes at this level can be safely ignored by SDK developers as they do not alter the protocol's behavior or surface.

This structured approach ensures that the impact of any given release is immediately understandable to the community.

1.2. Branching & Tagging Strategy

We recommend a hybrid strategy that leverages a primary development branch with automated tagging to ensure both stability and clear release demarcation.

• main Branch: The main branch will serve as the primary development branch, always reflecting the "next" state of the protocol. All new features and patches will be merged into main.
• Git Tags (vX.Y.Z): A permanent, annotated Git tag will be created for every official release (e.g., v1.2.0). Tags are immutable pointers to a specific commit, serving as the definitive marker for a release version. The creation of these tags and their corresponding GitHub Releases will be automated.
• Release Branches (release/vX.Y.Z): For major, complex releases that require a longer stabilization period, a dedicated release branch may be created from main. This allows for final testing and bug fixing without halting new feature development. However, for most minor and patch releases, this will not be necessary due to the automated process.

1.3. Commit and Release Automation

To streamline the release process, ensure consistency, and reduce manual overhead, we will adopt the following automated practices.

• Conventional Commits: All commits merged into the main branch must adhere to the Conventional Commits specification. This format prefixes commit messages with a type (e.g., feat:, fix:, docs:) and can include a BREAKING CHANGE: footer. This structured approach is fundamental to our release automation, as it allows tools to automatically determine the significance of changes.

• Automated Releasing with release-please: The process of version bumping, changelog generation, and creating GitHub Releases will be fully automated using the release-please GitHub Action. This tool works by:

  1. Analyzing commits on the main branch since the last tag.
  2. Determining the correct next semantic version based on the Conventional Commit messages (fix: bumps the patch, feat: bumps the minor, and BREAKING CHANGE: bumps the major).
  3. Opening a "Release Pull Request" that contains the proposed version bump and a draft changelog.
  4. Once this PR is reviewed and merged, the action automatically creates the corresponding Git tag and publishes the formal release on GitHub.

1.4. Release Cadence

To ensure the protocol evolves steadily and the community receives updates in a predictable manner, we propose a monthly release cycle.

• Predictability: The release-please Pull Request will be merged on a regular monthly schedule. This helps manage community expectations and allows SDK maintainers to plan their development cycles around a predictable release date.
• Batching Changes: A monthly cycle encourages batching several smaller changes into a single, coordinated release, providing a consistent stream of improvements.
• Release Candidates: To de-risk the monthly cadence and provide SDK developers with early access, we can create pre-releases (e.g., v1.2.0-rc.1) by manually triggering the release workflow on a release branch or by merging the Release PR with a pre-release version number.
• Flexibility: While the goal is a monthly release, this cadence is not rigid. If a month has no significant changes ready, a release can be skipped. Conversely, critical patch releases can be issued outside the regular schedule by simply merging the release-please PR as soon as a fix: commit lands in main.

This automated and structured approach balances the need for rapid innovation with the stability required by the broader ecosystem, while ensuring every release is well-documented through automatically generated changelogs.