[aliaksandr-kazarez]

Summary

Adds the release pipeline, modelled on session-replay-flutter. It stacks on #50 (the 0.1.0-alpha.1 release), which sits on main. On every push to main the workflow runs the unit-test matrix, then amplitude/actions/release-please-action opens or updates a release PR from conventional commits. When a release PR merges, the same action creates the GitHub release and its tag. SPM has no registry, so the tag is the publish. The release tags ruleset makes a v* tag immutable once created, so the workflow is arranged to get each tag right the first time.

The action is not googleapis/release-please. It reimplements it (release-please-action/index.js, 654 lines). It has no bootstrap-sha and no Release-As, and it finds the commits to release by comparing against the tag for the manifest version. With no tag it compares main...main and proposes nothing. So the first release, v0.1.0-alpha.1, is tagged by hand from #50's merge, which carries the constant and the changelog. This PR starts the manifest at 0.1.0-alpha.1 to match. Its first run on main compares against that tag, finds only this ci: commit, and proposes nothing. After that, the action takes over: feat, fix and breaking changes all bump alpha.N to alpha.N+1.

Verify before tagging. The release job needs a verify job that calls unit-test.yml, so a tag is only cut on a commit whose iOS/macOS/tvOS matrix is green. unit-test.yml and lint.yml drop their push: main triggers. The matrix still runs once per merge, inside verify. Lint on main gated nothing and ran on a billed larger runner.

Version drift check. The action's file updater silently skips a file whose x-release-please-version marker is gone, which would ship a tag reporting a different version on every event. lint.yml now fails when .release-please-manifest.json and StreamingAnalyticsInfo.version disagree. Lint is a required check, so a drifted release PR cannot merge. README.md and the four docs/ pages join extra-files; #50 adds their markers.

Credentials, per the security review.

• GITHUB_TOKEN gets nothing (permissions: {}), except contents: read for verify. Every write goes through the App token.
• The App token is narrowed to contents: write and pull-requests: write. Labelling a PR needs nothing more.
• The release job runs in a release environment that only main can deploy to. The App key is therefore released only to runs on main, not to a workflow any collaborator pushes on a branch.
• Pinned: create-github-app-token at bcd2ba49 (v3.2.0), the release action at 820754f (v0), runner ubuntu-24.04, 10-minute timeout. Runs queue rather than cancel, because a run killed between the tag and the release would leave a tag no one can move.

Needs before merging: the App installed on this repo, and SDK_RELEASE_BOT_APP_ID / SDK_RELEASE_BOT_PRIVATE_KEY added as secrets of the release environment. Without them, the token step fails on every push to main.

Graduating to 1.0.0. In one PR, remove versioning, prerelease and bump-minor-pre-major, and title it as a breaking change, for example feat(sdk)!: graduate to 1.0.0. The semantic-title check rejects an unscoped feat!:.

Validation

• Rebased onto chore: release 0.1.0-alpha.1 #50 at c5f6fce: the manifest and constant are both 0.1.0-alpha.1, and every workflow file parses. Before the rebase, at 61ad843 on main, all checks were green. The version check proved itself at d8896a0, failing on manifest 0.1.0-alpha.1 != StreamingAnalyticsInfo.version 0.0.0.
• I simulated the action's own code at 8091f292 (its bumpVersion and updateGenericFile) with this config:
  • From 0.1.0-alpha.1, feat, fix and feat(sdk)! each give 0.1.0-alpha.2.
  • With the graduation keys removed, feat(sdk)! gives 1.0.0, feat gives 0.2.0 and fix gives 0.1.1.
  • Over chore: release 0.1.0-alpha.1 #50's files, the updater rewrote only the marked version strings.
• I ran the version check locally in three cases. Matching versions pass, a drifted constant fails, and a missing constant fails with a distinct message.
• Not exercised: release-please.yml runs only on pushes to main. The verify → release chain, the environment and the narrowed token are first proven by the merge of this PR.

Checklist

• Does your PR title have the correct title format?
• Does your PR have a breaking change?: No. Only CI and release configuration change; there is no source or public API change.

---

Prepared with Claude. LLMs make mistakes — please verify before acting.

[Copilot]

🟡 Changes recommended

The first-version behavior, graduation instructions, and mutable privileged action reference need correction.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Adds automated prerelease versioning, changelog generation, tagging, and GitHub Releases via release-please.

Changes:

• Configures alpha releases and Swift version-file updates.
• Adds manifest-based version tracking.
• Adds a GitHub App-authenticated release workflow.

File summaries

File	Description
release-please-config.json	Defines prerelease and version-update behavior.
.release-please-manifest.json	Initializes package version tracking.
.github/workflows/release-please.yml	Runs release-please on main.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 3
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Copilot review overview

🟡 Changes recommended

Release authentication and the initial history cutoff remain unresolved, preventing a reliable first release.

Get a fresh assessment by requesting another Copilot review.

Review effort: Balanced
Findings: 1 · 1

Open (2)

• Missing GitHub App credentials will break every main push · New
• Missing bootstrap SHA causes first release to scan all history · New

Resolved since last review (3)

• This mutable v0 reference is given the repository-write GitHub App token, so moving the tag can…
• This does not produce the v0.0.1-alpha.1 first release promised by the PR description. With…
• These graduation steps will not make the next release v1.0.0. Removing the prerelease versioning…

[jlmitra-ampl]

Reviewed for least privilege. The pattern matches session-replay-flutter, and it's tighter in several places (SHA pins, the verify gate, queued concurrency). Three permission-scoping comments are inline.

Two repo-settings items sit outside this diff; I'll raise them separately:

• The release tags ruleset blocks delete, update and force-push on v*, but it doesn't restrict creation. Anyone with write access, or any workflow token with contents: write, can create a release tag. For SPM that is a publish, and it can't be undone. Suggest adding a creation rule with the release App as the only bypass.
• Actions settings: switch the default workflow permission to read, and turn off "Allow GitHub Actions to create and approve pull requests".

Unrelated to permissions: the # v0 comment on 8091f292 is 5 commits behind the current v0 tag (820754f). Those commits don't touch release-please-action, but the comment is misleading.

[jlmitra-ampl]

Least privilege: GITHUB_TOKEN doesn't need write here. Every write in this workflow goes through the App token. release-please-action only falls back to github.token when token is empty, and the token step fails before that can happen. So these two grants go unused. They also flow into the verify job. unit-test.yml's own contents: read caps them there, but only by accident. (This came over from session-replay-flutter, which has the same over-grant.)

Suggest denying everything at the top level and granting per job:

Suggested change

	permissions:
	contents: write
	pull-requests: write
	permissions: {}

and then:

  verify:
    permissions:
      contents: read
    uses: ./.github/workflows/unit-test.yml

  release-please:
    permissions: {}

[jlmitra-ampl]

Narrow the App token. With no permission-* inputs, the token gets every permission the App's installation has. That matters most if we use the org-wide SDK release bot. release-please only needs contents and pull requests. It's already limited to this repo by default, since owner/repositories are unset.

Suggested change

	uses: actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1 # v3.2.0
	with:
	app-id: ${{ secrets.SDK_RELEASE_BOT_APP_ID }}
	private-key: ${{ secrets.SDK_RELEASE_BOT_PRIVATE_KEY }}
	uses: actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1 # v3.2.0
	with:
	app-id: ${{ secrets.SDK_RELEASE_BOT_APP_ID }}
	private-key: ${{ secrets.SDK_RELEASE_BOT_PRIVATE_KEY }}
	permission-contents: write
	permission-pull-requests: write

If labelling the release PR fails (autorelease: pending), add permission-issues: write.

[jlmitra-ampl]

Keep the App key behind an environment. Put the App ID and private key in a release environment that only main can deploy to (Settings → Environments → Deployment branches: main). This repo is public and its default workflow permission is write. Any collaborator can open a pull request from a branch in this repo that adds a pull_request workflow, and that workflow can read repo-level secrets. Environment secrets are only released to jobs running on main. This applies directly if we go the repo-scoped App route, as session-replay-flutter does. If we stay on the org secrets instead, they should be limited to selected repositories.

Suggested change

	runs-on: ubuntu-24.04
	runs-on: ubuntu-24.04
	environment: release

[jlmitra-ampl]

approving conditionally pending addressing comments