Target timeline

Current state: Released

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.
• 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 pages and man page. 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 master 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
• N Tag a beta release
  • [N] Inform emlynmac for signing on macOS, and upload signed binary from his repo to ours
  • [N] Announce the beta release on Github Discussions. Pin the thread. See reminders at the end of this issue.
  • [N] 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).
  • Remove nb_NO translation if no translation has arrived yet
  • 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, see reminders at the end of this issue.
• 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.
  • Update check list regarding at what stage Mac builds should be signed and who can do it
  • There have been changes for 3.9.1 (Wikipedia mention, Mac signing). Do update the check list template.
• Unpin and close this issue
• Determine if a release retrospective is needed, create on Discussions if required

Reminders for the release announcement

• Build: Mac: Add universal binary and -dev build ad-hoc signing support #2808 needs listing to inform Mac users about the "gone" arm64 build
• Autobuild: Add Linux .deb aarch64 (Raspberry) 64bit builds #2895 needs a short listing in the release announcement
• Server: Correct handling of server list entry zero #2812
• Server: Command-line-specified country ID interpretation changed after switch to 3.9.0/Qt6 #2809 needs listing to inform Qt6-build users that they might have to "fix" this issue again if they've already changed the codes manually
• Newly connected empty clients don't show up on old clients #2754
• Client: Pass through flag for ctrlmidich used #2839 --cleanuplegacyfadersettings should be used by users of --ctrlmidich who have corrupt saved fader settings files (including in any inifiles) once per file. Also add a comment to https://github.com/orgs/jamulussoftware/discussions/2678.