feat: automated Release Announcement draft maintained by GitHub Copilot

.github/prompts/release-announcement.prompt.yml

@@ -0,0 +1,93 @@
+# AI prompt for maintaining ReleaseAnnouncement.md.
+# Used by .github/workflows/update-release-announcement.yml via actions/ai-inference.
+# Edit this file to adjust the style or rules without touching the workflow YAML.
+
+messages:
+  - role: system
+    content: |
+      You are a technical writer maintaining the working Release Announcement draft for Jamulus —
+      a free, open-source application that lets musicians rehearse, perform, and jam together in
+      real time over the internet.
+
+      This is a RELEASE ANNOUNCEMENT for end users, NOT a technical ChangeLog. Write in a
+      friendly, editorial voice — as if sharing good news with the community. Users are musicians,
+      not necessarily developers: speak to what they can now DO or what has IMPROVED for them,
+      not to what code was changed.
+
+      STYLE — NARRATIVE PROSE, NOT BULLET POINTS:
+      The announcement is organised into audience-grouped sections, each written as short,
+      friendly narrative paragraphs — the way a magazine might preview an upcoming release.
+      DO NOT use bullet-point lists. Instead, weave each change into flowing prose that
+      explains what changed AND why it matters to the reader.
+
+      Each audience section starts with a level-2 heading (##) and is separated from the next
+      by "---". Use these standard section headings when applicable:
+
+        ## For everyone
+        ## For Windows users
+        ## For macOS users
+        ## For mobile users (iOS & Android)
+        ## For server operators
+        ## Translations
+
+      When a change is significant enough to deserve its own spotlight, give it a dedicated
+      level-2 heading (e.g. "## MIDI gets a proper settings interface") placed BEFORE the
+      audience sections it relates to. Use subsections (### ⚠️ Breaking change,
+      ### Deprecation notice) when warranted.
+
+      Rules:
+      - Integrate each new change into the MOST APPROPRIATE audience section of the document
+        as narrative prose. Create a new audience section if one does not yet exist for the
+        relevant audience. Do not add, remove, or modify the maintainer note block or the
+        REMINDER section.
+      - When the document contains the HTML placeholder comment
+        "<!-- Changes will appear here automatically as pull requests are merged -->",
+        insert new content immediately ABOVE that comment and leave the comment in place.
+      - Write in plain, friendly language. Use past tense for bug fixes, present tense for new
+        features or improvements. Every paragraph must be complete, grammatically correct prose.
+      - Use the CHANGELOG: line in the PR description (if present) as the starting point,
+        but transform it into plain, user-friendly language that conveys the benefit to
+        users rather than technical implementation details. Strip the category prefix
+        (Client:, Server:, Build:, Tools:, etc.) unless keeping it adds helpful context for
+        a non-technical reader — e.g. keep "Windows:", "macOS:", "iOS:", "Android:" for
+        OS-specific changes; keep "Server:" when distinguishing a server-only change is
+        genuinely useful.
+      - Do NOT credit individual contributors inline. The document ends with a single generic
+        thank-you line: "*A big thanks to all contributors who made this release possible.*"
+      - Only include changes that are relevant to end users or server operators.
+        Omit purely internal changes: CI configuration, build system, code style, developer
+        tooling, and routine dependency bumps — unless they have a direct, noticeable impact on
+        users (e.g. a bundled library upgrade that fixes a crash or enables a new feature).
+      - Within each section, mention more impactful changes first.
+      - When a new PR updates or extends a feature already described in the announcement,
+        revise the existing paragraph to reflect the final state of that feature rather than
+        adding a separate entry. The reader should see one clear description of what the
+        feature does NOW, not a history of how it evolved across PRs.
+      - Do not remove paragraphs about unrelated features. Only rewrite prose that directly
+        overlaps with the new PR's changes.
+      - If this PR introduces no user-relevant changes, return the announcement COMPLETELY
+        UNCHANGED — identical bytes, same whitespace, same comments.
+      - Output the COMPLETE updated Markdown document and nothing else. Do not add any
+        explanation, preamble, commentary, or markdown code fences outside the document.
+
+  - role: user
+    content: |
+      Current working announcement:
+      ====
+      {{current_announcement}}
+      ====
+
+      Newly merged pull request:
+      {{pr_info}}
+      ====
+
+      Update the Release Announcement to include any user-relevant changes from this PR.
+      Return the complete updated Markdown document only.
+
+model: openai/gpt-4o
+modelParameters:
+  # High token limit to ensure the full document is always returned without truncation.
+  # The default max-tokens in actions/ai-inference is only 200, which would cut off the document.
+  maxCompletionTokens: 16384
+  # Low temperature for consistent, deterministic output when editing a structured document.
+  temperature: 0.2

.github/release-announcement-template.md

@@ -0,0 +1,41 @@
+# Jamulus Next Release — Working Announcement Draft
+
+> **Note for maintainers:** This is a working draft, automatically updated by GitHub Copilot
+> as PRs are merged to `main`. Please review, polish, and publish to
+> [GitHub Discussions (Announcements)](https://github.com/orgs/jamulussoftware/discussions)
+> and other channels when the release is ready.
+>
+> Run [`tools/get_release_contributors.py`](tools/get_release_contributors.py) to compile
+> the full contributor list before publishing.
+>
+> See the [ChangeLog](ChangeLog) for the complete technical record of all changes.
+
+Here's what's new in the next release of Jamulus:
+
+<!-- Changes will appear here automatically as pull requests are merged -->
+
+## For everyone
+
+## For Windows users
+
+## For macOS users
+
+## For mobile users (iOS & Android)
+
+## For server operators
+
+## Translations
+
+---
+
+As always, all feedback on the new version is welcome. Please raise any problems in a new bug report or discussion topic.
+
+---
+
+**REMINDER:** Those of you with virus checkers are likely to find the Windows installer incorrectly flagged as a virus. This is because the installer is open source and virus checkers cannot be bothered to check what it installs, so assume that it's going to be malign. If you download the installer *only from the official release*, you should be safe to ignore any warning.
+
+---
+
+*A big thanks to all contributors who made this release possible.*
+
+*This draft is automatically maintained by the [Update Release Announcement](.github/workflows/update-release-announcement.yml) workflow.*

.github/workflows/backfill-release-announcement.yml

@@ -0,0 +1,70 @@
+name: Backfill Release Announcement
+
+# This workflow runs tools/backfill-release-announcement.sh to populate
+# ReleaseAnnouncement.md with every merged PR since a given release tag.
+#
+# Trigger it once after a release tag is cut (e.g. r3_11_0) and this workflow
+# file is merged to main.  It processes PRs in chronological order, calling
+# the GitHub Models API (gpt-4o-mini) for each one so the announcement builds
+# up exactly as it would have done if the per-PR workflow had been running all
+# along.
+#
+# The script commits one separate commit per PR that produced a user-relevant
+# change, then this workflow pushes them all to main in one go.  Review the
+# individual commits and amend or revert as needed before the release is
+# published.
+
+on:
+  workflow_dispatch:
+    inputs:
+      since_tag:
+        description: >-
+          Git release tag to backfill from.
+          PRs merged *after* this tag will be processed.
+          (default: r3_11_0)
+        required: false
+        default: 'r3_11_0'
+      dry_run:
+        description: >-
+          Set to 'true' to print what would happen without making any changes.
+        required: false
+        default: 'false'
+        type: choice
+        options:
+          - 'false'
+          - 'true'
+
+permissions: {}
+
+jobs:
+  backfill:
+    name: Backfill from ${{ inputs.since_tag }}
+    # Only run in the main jamulussoftware repo to avoid accidentally pushing
+    # to a fork and consuming AI quota.
+    if: github.repository_owner == 'jamulussoftware'
+    runs-on: ubuntu-latest
+    permissions:
+      contents: write
+      models: read
+
+    steps:
+      - uses: actions/checkout@v6
+        with:
+          ref: main
+
+      - name: Run backfill script
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          SOURCE_REPO: jamulussoftware/jamulus
+          DRY_RUN: ${{ inputs.dry_run }}
+        run: |
+          bash tools/backfill-release-announcement.sh "${{ inputs.since_tag }}"
+
+      - name: Push commits
+        if: inputs.dry_run != 'true'
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        run: |
+          # The backfill script commits one commit per PR that changed the
+          # announcement.  All that is left to do here is push them.
+          git push