version-check

To determine the correct semantic version bump, analyze non-merge git commits since the latest v*.*.* tag, classify Conventional Commit semantics including breaking-change detection, and output a major, minor, or patch recommendation.

Automating release planning with conventional commits involves mapping commit message prefixes into feature, fix, and breaking categories to produce a changelog-style breakdown and validate release readiness before applying a version bump.

Checking release readiness after merging changes requires listing commits since the highest version tag, detecting breaking-change signals, and generating a suggested update for gradle.properties to prepare the new release.

Semantic-release validation integrates with gradle.properties by checking the current nimbusVersion value, comparing it against the recommended semver bump derived from the git commit history analysis.

A breaking change signals a major semver bump because Conventional Commit semantics dictate that any modification breaking backward compatibility requires incrementing the major version instead of minor or patch.

You should avoid relying solely on an automated semver bump recommendation when your git history lacks Conventional Commit prefixes, as the classification logic cannot accurately detect features, fixes, or breaking changes.