semver

To determine the correct semantic version bump, classify code, API, or configuration changes as major, minor, or patch. Apply these rules to pull requests and release notes to ensure releases communicate compatibility expectations and avoid breaking downstream consumers.

You need a major version bump for breaking changes when introducing incompatible API, CLI, configuration, or runtime removals. Signature changes that require existing consumers to update their code also mandate a major version increment to signal lost backward compatibility.

In semantic versioning, a minor release covers backward-compatible additions like new endpoints or optional parameters, whereas a patch release covers backward-compatible fixes such as bug fixes, security patches, and internal refactors that do not change the public interface.

Automate release tags and changelog generation in CI workflows by classifying pull request descriptions to recommend major, minor, or patch increments. This ensures consistent semantic versioning across automated release pipelines by selecting the highest applicable level when multiple change types are present.

When multiple change types are present in a single pull request, you must select the highest applicable version bump level. If the impact on API, CLI, configuration, or dependencies remains uncertain, prefer a major version bump to protect downstream consumers.

Removing platform support requires a major version bump because it introduces incompatible changes for users on that platform. Advising on dependency or platform support removals ensures the semantic version correctly signals breaking changes to affected consumers.