Add automated release workflow with release-please for semantic versioning

### Problem croc currently relies on manually creating GitHub Releases to trigger the build and publish pipeline. While the downstream automation is excellent -- `release.yml` builds 21 platform/arch binaries, `deploy.yml` pushes multi-arch Docker images, and `winget.yml` publishes to Windows Package Manager -- the version determination and release creation itself is entirely manual. With 183 releases over the project's lifetime, this has been a significant amount of manual work. As a largely single-maintainer project, this also means releases can only happen when @schollz is available to create them. Specific pain points: - **No enforced link between changes and version bumps** -- it's easy to accidentally ship a breaking change as a patch, or forget to bump minor for new features. - **No structured changelog** -- users have to scan raw commit lists to understand what changed between releases. - **Bus factor risk** -- if the maintainer is unavailable, releases stall. Contributors can land PRs but can't ship them. - **183 manual releases and counting** -- this is time that could be spent on the project itself. ### Proposed Solution Adopt [**release-please**](https://github.com/googleapis/release-please) to automate version determination and release creation. release-please is a Google-maintained GitHub Action that: 1. **Monitors commits on `main`** using [Conventional Commits](https://www.conventionalcommits.org/) prefixes (`feat:`, `fix:`, `chore:`, `BREAKING CHANGE`, etc.). 2. **Automatically determines the next semver version** -- patch for `fix:`, minor for `feat:`, major for breaking changes. 3. **Opens and maintains a "Release PR"** containing the version bump and an auto-generated `CHANGELOG.md`. This PR updates continuously as new commits land. 4. **Creates the GitHub Release only when a maintainer merges the Release PR** -- this is the critical safety gate. No release ships without explicit human approval. **Why this fits croc well:** - The existing `release.yml`, `deploy.yml`, and `winget.yml` workflows all trigger on `release: types: [created]` -- they would need **zero changes**. release-please creates a standard GitHub Release, which triggers all three downstream workflows exactly as they work today. - The project already follows semver in its tags (`v10.4.2`, `v10.4.1`, `v10.4.0`, etc.), so this is a natural evolution. - The `.goreleaser.yml` config that still exists in the repo (but appears unused by current workflows) could be cleaned up as part of this work. - Maintainer retains full control over release timing by choosing when to merge the Release PR -- changes can be batched, versions can be adjusted, and the changelog can be reviewed before shipping. **Implementation would involve:** - Adding `release-please-config.json` and `.release-please-manifest.json` to the repository root (bootstrapped from the current `v10.4.2`). - Adding a `release-please.yml` workflow that runs on pushes to `main`. - Optionally adopting Conventional Commits as a commit message convention (can be introduced gradually). - No changes needed to `release.yml`, `deploy.yml`, or `winget.yml`. ### Alternatives Considered **[semantic-release](https://github.com/semantic-release/semantic-release):** Fully automatic -- publishes a release on every qualifying push to `main` with zero human intervention. This removes the manual merge gate, meaning every `feat:` or `fix:` commit would trigger a release immediately. This could work well for croc given its maturity, but offers less control over release timing and batching. **Keep the current manual process:** Works, but 183 releases in, the overhead is clear. ### Contribution I have experience implementing release-please and semantic-release workflows for open-source projects and would be happy to submit a PR for this if you're interested in moving towards automated release cycles.