ci: release with release-please, as in port-bridge

[gabrielfrasantos]

Summary

Replaces the tag-driven release (setuptools-scm) with release-please, set up the same way as in port-bridge.

How a release works after this PR:

1. Release PR. Every push to main runs release-please.yml. It opens or updates a chore(main): release X.Y.Z pull request, which bumps version in pyproject.toml and the manifest and adds the notes to CHANGELOG.md.
2. Merging it creates the vX.Y.Z tag and the GitHub release. The same run then:
   • release.yml builds the sdist and wheel, checks the version against the tag, and attaches the files to the release.
   • build-installers.yml builds the Windows installer and the Linux AppImage and attaches them.
   • publish uploads to PyPI with trusted publishing.
     • It sits in release-please.yml because PyPI identifies the top-level workflow, as in port-bridge.
     • The PyPI publisher is: workflow release-please.yml, environment pypi.

Changes

• Version: now static at 0.1.0 in pyproject.toml and managed by release-please. setuptools-scm is removed.
• New files:
  • release-please-config.json and .release-please-manifest.json. They're the same as port-bridge's (python release type, extra-files for the pyproject version), apart from the package name.
  • .github/workflows/release-please.yml with the jobs release-please → release + installers, then publish.
• release.yml: now started by release-please.yml or by hand with tag_name (to backfill a tag); it no longer runs on a pushed tag. It builds the package files and attaches them to the existing release.
• build-installers.yml / ci.yml: fetch-depth: 0 is gone; only setuptools-scm needed it.
• CHANGELOG.md: now in release-please format. The hand-written Unreleased notes move into the seed commit, described below.
• CONTRIBUTING.md: documents the commit convention, the release flow and the one-time setup. The README links to it.

First release: 0.2.0

The commit message of this PR carries extra Conventional Commit entries (feat: for the remote server, the GUI and URL ports, and a build: entry) plus Release-As: 0.2.0. release-please reads several entries from one commit message, so the first release PR is 0.2.0, with those features in its notes.

➡️ Merge with a merge commit or a rebase, not a squash. Otherwise those footer lines may not reach main.

One-time setup (also in CONTRIBUTING.md)

• Settings → Actions → General → Workflow permissions: turn on Allow GitHub Actions to create and approve pull requests.
• PyPI (Your account → Publishing): add a pending publisher with project ad3-waveforms-bench, owner embedded-pro, repository ad3-waveforms-bench, workflow release-please.yml, environment pypi.
• Settings → Environments: create pypi, optionally with required reviewers.
• Optional: add a RELEASE_PLEASE_TOKEN secret (a fine-grained token with Contents and Pull requests read/write access). PRs opened with GITHUB_TOKEN don't trigger CI.

Testing

• ruff check, ruff format --check and mypy are clean. 137 tests pass (GUI tests run offscreen), with 85% coverage.
• python -m build produces ad3_waveforms_bench-0.1.0 (sdist and wheel), and twine check --strict passes.
• The workflow's version check passes for v0.1.0, and the installed wheel reports __version__ == "0.1.0".
• The workflow YAML files and both JSON files parse.
• Only verifiable after merge: the release-please run on main should open chore(main): release 0.2.0 with the seeded features.

🤖 Generated with Claude Code

https://claude.ai/code/session_01TPQkhNKUR1hxzoycY8R9VV

---

Generated by Claude Code