Prepare release 3.11.0

[ann0see]

Target timeline
Scheduled feature freeze / Start of translation process:
Targeted translation completion date:
Approximate release date:
Current state:

Checklist

• Assign this issue to the release shepherd who is in charge of managing this checklist.
• Pin this issue
• Ensure that all issues/PR targeted for this release are done by checking the Project board with the appropriate filter for this release. Remind main developers to review entries in Waiting on team state.
• Agree to de-tag unfinished Issues/PRs.
• Declare a freeze for code and website by updating this Issue and adding a comment. PRs can still be worked on and may get reviewed, but must not be merged unless agreed explicitly.
• Check the needs documentation label for any outstanding PRs flagged for this release and remove that label if done.
• Check ./Jamulus -h output against the Include-Client/Server-Commands.md pages and [man page (distributions/Jamulus.1)[(https://github.com/jamulussoftware/jamulus/blob/main/distributions/Jamulus.1). Update if necessary.
• Start Website translations
  • Check for broken links
  • Open a Pull Request from next-release to release, set it as "Draft", sanity check for conflicts and any obvious problems.
  • Declare a full freeze of the next-release and release branch. No changes should be made from now on to ensure translators don't have to work twice.
  • Check if the list of translators in tools/create-translation-issues.sh. Make sure issue text is up-to-date. Add any URLs that will need localisation into the "New/Changed screenshots" section.
  • Create a translation issue for each language with tools/create-translation-issues.sh using web argument (see notes in script).
  • If anyone finds critical issues now, all translators must be made aware of them and all languages should be updated.
• Start App translations
  • Generate .ts files in main via lupdate
  • Check if the list of translators in tools/create-translation-issues.sh is up-to-date
  • Create a translation issue for each language with tools/create-translation-issues.sh using app argument.
• Update the Changelog
• Tag a beta release
  • Inform emlynmac for signing on macOS, and upload signed binary from his repo to ours
  • Announce the beta release on Github Discussions. Pin the thread.
  • Get feedback on the stability and resource usage (memleaks?, crashes?, installation issues?) of the beta release
• Finish App translations
  • Review translation PRs according to release process checklist
  • Wait for all PRs to be merged (missing translations will revert to English automatically).
  • Check for conflicting accelerator keys (see tools/checkkeys.pl)
  • Generate .qm files via lrelease Jamulus.pro
• Finish Website translations
  • Wait for all PRs to be merged (missing translations will revert to English automatically)
  • Check for broken links
• Check the milestone for mergable stuff again
• Update the Changelog
• Tag a release candidate (inform emlynmac for signing on macOS and upload signed binary from his repo to ours).
  • Announce the release candidate on Github Discussions. Pin the thread. Unpin and lock the beta thread.
  • Draft an announcement, include all contributors via tools/get_release_contributors.py
• Update the version number in Jamulus.pro and add the release date to the Changelog header and commit
• Update the Changelog
• Tag this commit as r3_y_z
  • Wait for the build to complete
  • Contact emlynmac for signing on macOS and upload signed binary from his repo to ours.
  • Do a smoke test for Windows/Mac/Linux -- Do the binaries start/connect properly? Can earlier Jamulus versions properly connect to a server based on the new release?
  • Force tag that tag as latest and push.
  • Upload the artifacts to SourceForge and set defaults.
  • Update download links on the website by editing _config.yml in next-release
  • Disable branch protection rule of the release branch by clicking on "Edit" on the Branches page and adding a _ behind release.
  • Publish Website release by squashing and merging next-release into release
  • Enable branch protection rule of the release branch after the site and the .po files are published by removing the _ from the branch protection rule you edited on the Branches page.
• Announce the new release with a summary of changes (+ link to the changelog for details) and a link to the download page
  • On Github Discussions in the Announcements section. Lock the announcement thread. Pin the thread. Unpin and lock release candidate thread.
  • On Facebook in the group "Jamulus (official group)". Turn off replies.
• Trigger the update notification by updating both Update Check Servers with the new version (@pljones for update02, email corrados for update01)
• [Prepare Jamulus.pro (dev suffix) and ChangeLog (add a header) for the next release
• Check that all Issues and PRs tagged for this release are in Done/Closed state.
• Close the release milestone in both jamulus and jamuluswebsite repos
• Create a milestone for the next minor release in jamulus and jamuluswebsite repos
• Update this template in https://jamulus.io/contribute/Release-Process with any improvements if needed.
• Unpin and close this issue
• Determine if a release retrospective is needed, create on Discussions if required