Prepare release 3.12.0

[pljones]

Target timeline

Phase	Date
Scheduled feature freeze / Start of translation process	06.07.2025
Targeted translation completion date:	Early 2025
Approximate release date:	Early 2026
Current state:	Code freeze (rc)

Release aims

We're currently looking forwards to Jamulus 4, which will make some larger scale changes to parts of Jamulus than previous releases have. So we're aiming to fix as many known issues as we can in this coming release, so there's a stable version of Jamulus available whilst work progresses on the changes.

Checklist

• Assign this issue to the release shepherd who is in charge of managing this checklist.
• Make sure ChangeLog has the agreed next release version number.
• 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)
• 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 (push the tag to ann0see/jamulussign for signing on macOS and upload signed binary to the official one).
  • 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 Changelog
• Tag the release version:
  • Update the version number in Jamulus.pro and add the release date to the Changelog header and commit.
  • Wait for the release build to complete.
  • Push the release to ann0see/jamulussign for macOS signing and upload signed binary from the signing repo repo to the official one.
  • 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?
  • Do a smoke test of the upgrade notification (do this very quickly)
    • Install the release build on one of the update notification Servers
    • Run the previous release (not an intermediate) build of GUI Client and Server
    • Check the update notice is displayed correctly
    • Revert the update notification Server to the previous 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
• Make sure there are no open issues or PRs on the Project Tracking Board for the milestone
• Create a milestone for the next minor release in jamulus and jamuluswebsite repos
• Change the Project Tracking Board to the next release (i.e. change the filter and save the change)
• Close the release milestone in both 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

[ann0see]

@pljones Could you please verify you sent a mail about discord a few minutes ago?

[pljones]

Yes. I've got to check a gew other places too see where else I did it, too.

[ann0see]

Ok. Verified. @gilgongo should be able to help you.

[ann0see]

I'd say the goal here is to have a stable 3.12.0 (@pljones already said something like that somewhere). Afterwards for 4.0 we start potential larger restructurings.

[ann0see]

I would like to declare a feature freeze this weekend: 05.07.25.

[anprdev]

Ho, What you mean this. Jamulus down?     Sent: Monday, June 30, 2025 at 6:31 PM From: "ann0see" ***@***.***> To: "jamulussoftware/jamulus" ***@***.***> Cc: "anprdev" ***@***.***>, "Comment" ***@***.***> Subject: Re: [jamulussoftware/jamulus] Prepare release 3.12.0 (Issue #3443) ann0see left a comment (jamulussoftware/jamulus#3443) I would like to declare a feature freeze this weekend: 05.07.25. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[ann0see]

@anprdev No. This means that from this date no new features for the upcoming version should be worked on. Every new feature worked on would need to be in a later version.

[anprdev]

  Thanks for answering. Cheers Roland   Sent: Tuesday, July 01, 2025 at 7:27 AM From: "ann0see" ***@***.***> To: "jamulussoftware/jamulus" ***@***.***> Cc: "anprdev" ***@***.***>, "Mention" ***@***.***> Subject: Re: [jamulussoftware/jamulus] Prepare release 3.12.0 (Issue #3443) ann0see left a comment (jamulussoftware/jamulus#3443) @anprdev No. This means that from this date no new features for the upcoming version should be worked on. Every new feature worked on would need to be in a later version. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>