Release terraform-provider-ec

Prepare a new release for the Terraform Provider for Elastic Cloud.

Determine version

If the user provided an explicit version like X.Y.Z, use that. Otherwise determine the bump type:

• $ARGUMENTS can be patch, minor, or an explicit version like 0.13.0
• If no argument is given, analyze the changes to decide:
  • patch: only bug fixes since last release
  • minor: any new features, enhancements, or breaking changes
  • No major releases — the project doesn't do major bumps yet
• Tell the user what version you're targeting and why before proceeding.

Step 1: Identify changes since last release

1. Find the last release tag: git describe --tags $(git rev-list --tags --max-count=1)
2. Get its date: git log -1 --format=%ai <tag>
3. Fetch all PRs merged since that date:

   gh pr list --repo elastic/terraform-provider-ec --state merged --search "merged:>YYYY-MM-DD" --json number,title,mergedAt --limit 100

4. Filter out dependency updates (fix(deps):, chore(deps):), CI changes (chore: actions/checkout, actions/setup-go, etc.), and the previous release prep PR.
5. For each remaining PR, check its .changelog/ entry. Flag PRs that look user-facing but have only release-note:none (or no entry at all — pre-check PRs). release-note:none is the correct signal for non-user-facing work; it must not appear under FEATURES/ENHANCEMENTS/BUG FIXES.

Step 2: Build changelog

1. Check existing .changelog/*.txt files in the repo.
2. IMPORTANT: Verify each .changelog/*.txt file's content matches upstream, not just the local copy. Use git show upstream/master:.changelog/NNN.txt or check GitHub.
3. Draft the full changelog section using the format from scripts/changelog.tmpl:
   • BREAKING CHANGES (release-note:breaking-change)
   • NOTES (release-note:note)
   • FEATURES (release-note:feature, release-note:new-resource, release-note:new-data-source)
   • ENHANCEMENTS (release-note:enhancement)
   • BUG FIXES (release-note:bug)
4. Include entries for user-facing PRs that are missing .changelog/ files.
5. Present the changelog draft to the user for review before writing any files.

Step 3: Apply changes

After the user approves the changelog:

1. Create a new branch: prep-X.Y.Z
2. Bump version in Makefile and ec/version.go to X.Y.Z-dev (keep the -dev suffix)
3. Update provider version (without -dev) in:
   • README.md
   • All files under examples/ that declare the ec provider You can use ./scripts/update-provider-version.sh X.Y.Z for this.
4. Write the new changelog section to CHANGELOG.md (prepend before the previous release)
5. Delete all .changelog/*.txt files, including release-note:none fragments (they are not rendered into CHANGELOG.md but would otherwise accumulate on master). Release-prep PRs also need their own .changelog/{PR}.txt with release-note:none.
6. Commit with message: Prepare X.Y.Z release

Step 4: Create PR

Ask the user before creating the PR. When approved:

• Push the branch
• Create PR with title Prepare X.Y.Z release targeting master

• Changelog follow-up (required): after the PR number is known, write .changelog/{PR}.txt with a release-note:none fence, commit it, and push. Step 3 deletes every fragment before the number exists, so without this follow-up commit Check PR changelog stays red. Example body:

  ```release-note:none
  ```

Step 5: Tag (after merge)

Only when the user explicitly asks to tag (typically after the PR is merged):

1. Ensure you're on master with the merge commit
2. Run make tag — it creates the vX.Y.Z tag (the VERSION minus its -dev suffix) and pushes it to the remote pointing at elastic/terraform-provider-ec, which triggers the Buildkite release pipeline.
3. Equivalently, tag and push by hand: git tag vX.Y.Z then git push <remote> vX.Y.Z, where <remote> is the one pointing at elastic/terraform-provider-ec (often upstream).
4. Do not gh release edit. make release (Buildkite) fills the GitHub release body from this version's CHANGELOG.md section (scripts/extract-release-notes.sh → GoReleaser --release-notes; changelog.disable in .goreleaser.yml would ignore that file). After the pipeline finishes, confirm gh release view vX.Y.Z --repo elastic/terraform-provider-ec shows that section (not an empty body).

Important rules

• Don't post anything to GitHub until the user explicitly asks.
• Always present the changelog for review before writing files.
• Keep -dev suffix in Makefile and ec/version.go.
• Verify .changelog/ file contents against upstream.
• Check all merged PRs, not just those with .changelog/ entries.
• Do not gh release edit for notes. make release copies CHANGELOG.md into the GitHub release via --release-notes (requires the GoReleaser changelog pipe to stay enabled).