Bump Semver

Bump Semver

Use the repository's version script instead of manually editing project files. The source of truth is Directory.Build.props, and release automation reads that version to decide whether to publish a new GitHub release.

Quick Start

Run from repo root:

./scripts/bump-version.ps1 -Part patch

Common Operations

Patch bump:

./scripts/bump-version.ps1 -Part patch

Minor bump:

./scripts/bump-version.ps1 -Part minor

Major bump:

./scripts/bump-version.ps1 -Part major

Start/increment prerelease:

./scripts/bump-version.ps1 -Part prerelease
./scripts/bump-version.ps1 -Part prerelease -PrereleaseLabel beta

Strip prerelease suffix (make stable release):

./scripts/bump-version.ps1 -Part release

Set an exact version:

./scripts/bump-version.ps1 -SetVersion 1.2.3
./scripts/bump-version.ps1 -SetVersion 1.2.3-rc.1

Preview only (no file write):

./scripts/bump-version.ps1 -Part patch -DryRun

Workflow

1. Read Directory.Build.props and confirm the current <Version>.
2. Run scripts/bump-version.ps1 with the requested SemVer action.
3. Report the old and new version values.
4. If release automation is part of the request, note that .github/workflows/publish.yml checks Directory.Build.props and only creates a release when the version tag does not already exist.
5. Suggest running dotnet build GeminiTtsCli.sln if the user wants post-change verification.

Notes

• Do not edit src/gemini-tts-cli.csproj to change the version; versioning is centralized.
• Use stable SemVer for production releases (for example 1.2.3).
• Use prerelease identifiers like -rc.1 or -beta.2 while testing.