Prepare Release 3.9.1

[hoffie]

Target timeline

Phase	Target date	Original	Actual
Scheduled feature freeze / Start of translation process	2022-09-24	2022-09-24	2022-09-21 (app translations)
Targeted translation completion date	2022-10-08	2022-10-08	2022-10-09 (app translations, forced)
Approximate release date	2022-10-15	2022-10-15	2022-10-17 (announcement 2022-10-21)

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.

[hoffie]

Note: I'm merely opening this now without any previous discussion to have a sane place to list reminders for the release announcement.

I think it makes sense to keep this release small. I haven't checked, but I think we haven't had anything translation-related, so we might be able to skip that and make it a real bugfix/very-small-feature release (as the versioning implies).

[pljones]

Warning: Can't create issue for nb_NO - who is responsible? Skipping.

Oops, I forgot about the new nb_NO app translations. Is there any way to use the script for a single language?

EDIT: I've raised the issue by hand but can't assign the issue to @comradekingu - presumably because they're not in "translators"?

[comradekingu]

@pljones I (just one person) can help fix issues in more languages if need be :)

[pljones]

If you want to liaise with the people assigned to the other languages, please do.

If you want to change the source text, please raise an appropriate pull request.

Thanks.

[ann0see]

@jamulussoftware/maindevelopers I think we should open the website translation issues as soon as possible (once we've confirmed the docs are up to date)

[pljones]

@jamulussoftware/maindevelopers I think we should open the website translation issues as soon as possible (once we've confirmed the docs are up to date)

This is why they've not been opened.

[ann0see]

@emlynmac could you please build the RC?

[ann0see]

The accelerator keys should be rechecked as we had a translation update

[ann0see]

@henkdegroot suggested to integrate Weblate into the release process a bit more: #2758 (comment)
This might need updates.

[ann0see]

3.9.1 GUI version works fine on my debian 11 machine. Sound is good.

[ann0see]

Windows ASIO and JACK also seem to work fine.

[ann0see]

macOS Legacy also seems ok

[ann0see]

macOS non legacy seems also ok.

[ann0see]

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.

After that we used to delete next-release or force push to it...

[chrisrimple]

Can someone please clarify: 3.9.1 released in October and is the default download on http://jamulus.io, but we're nearing release of an update that will have the same version number (rather than be 3.9.2)? I need to install a new server but may wait for the update if it's likely to get out in the next week or so. Thanks.

[ann0see]

3.9.1 is the version which just got released. 3.9.2 or 3.10.0 isn't even planned yet.

[hoffie]

As written in the chat, I think we shouldn't have changed the order of steps from the release check list regarding finalizing all builds (signed Mac build) and updating the download links on the website. The website currently provides an unsigned build for Mac users, which is a regression and might show unexpected warnings to users (we've already got one enquiry at team@).

To rectify that, I've now pushed the 3.9.1 tag to @emlynmac's repo. I'll upload the artifact to our release package once done.
@emlynmac I hope you are OK with that. You had granted me (and some other team members) write access to your repo for access to the signing logic (as part of the CodeQL-related debugging) in the past. I think we should clarify this part one way or the other. Either revoke our access or explicitly document that some (who?) team members can do that part themselves.

@chrisrimple To clarify further: 3.9.1 has been tagged and frozen. The only thing which will change (binary-wise) is that the Mac build will be replaced by the signed version shortly. It's just that the 3.9.1 release process is unusually stretched this time (most of the steps were usually done only some hours apart, while it's now days).

[hoffie]

I'll upload the artifact to our release package once done.

Well, I haven't been successful so far, the build gets stuck. The problem seems to be somewhere around the macdeployqt code signing part. I've started several debugging runs. It might be related to #2790. I will continue investigating later, but currently we can't build a signed Mac dmg.

[hoffie]

I might have found the underlying issue. I'm documenting it here: #2925. A 3.9.1 build with a fix included is currently running here: https://github.com/emlynmac/jamulus/actions/runs/3285054847/jobs/5411736285#step:10:1887

[hoffie]

The fix works and makes the build complete. @emlynmac did a successful test. I've therefore taken the build from @emlynmac's repo and replaced the unsigned one in our 3.9.1 release.

@pljones @ann0see: Should I modify the r3_9_1 tag to include #2927? I think we had a similar case with debian a few releases ago and I think we hadn't modified the tag there.

[pljones]

@pljones @ann0see: Should I modify the r3_9_1 tag to include #2927? I think we had a similar case with debian a few releases ago and I think we hadn't modified the tag there.

As we've not moved latest, I think moving r3_9_1 is justified.

[hoffie]

According to the check list and to git, latest is at 3.9.1 already.

[pljones]

Now I'm getting very confused. We've not put out the release announcement - that and the tag should go hand in hand. (Ideally, the Github "tag" wouldn't move until our latest tag moved.

The signed builds should run from the r3_9_1 tag, then the Github release get updated with those builds, then the release announcement and latest tag can be done.

[hoffie]

Now I'm getting very confused. We've not put out the release announcement - that and the tag should go hand in hand. (Ideally, the Github "tag" wouldn't move until our latest tag moved.

We are talking about two kind of "latest" tags here though:

• The Github "latest" release badge on the release (I think it is added automatically when CI completes, although we can manually mark older releases as latest).
• The git tag "latest", which we update for historical reasons (I still find this process strange and have no feeling who uses it for what reasons; if anything, a branch would make more sense than a tag, I guess?). As far as I understand, this Git tag is totally unrelated to the Github badge.

The status quo for 3.9.1 is:

• The Github "latest" badge is on 3.9.1.
• The git tag "latest" points to 3.9.1.

It might not have been optimal for now, but I guess we'll now keep that as-is?

The signed builds should run from the r3_9_1 tag, then the Github release get updated with those builds, then the release announcement and latest tag can be done.

See #2813 (comment) -- I had already done that in emlynmac's repo yesterday. My question about the r3_9_1 tag was solely about jamulussoftware/jamulus, as the tag currently points to a different commit (pre-signing fix) than in emlynmac's repo (which is post-signing fix).

Unless we want to be super-exact about aligning the r3_9_1 tag and replacing artifacts again (I wouldn't do that as it would imply that there are multiple files named "3.9.1" with different hashes floating around; might even make Windows acceptance harder). People already downloaded 3.9.1 as the Github release creation causes notifications and as the website has already been updated to link to 3.9.1.

So, my suggestion would be to continue with the check list and start publishing the announcement.

[pljones]

Yes, as we've got further than I thought.

[pljones]

"latest" was what was being pulled by "Simon's Script" when it built from source, IIRC, before it installed the .deb. I think it's also something was quite common: "latest" referencing the latest stable build... Such usage is generally now deprecated, in favour of taking control of dependencies and knowing what your versions are. Whether that makes life simpler for more people or not, I don't know.

The problem on Github comes down to the version in Jamulus.pro making it think a particular build is a release, right? This seems to mean we can't "prepare" a release by pushing the commits with the release details in until we're really ready to:

1. tag that as the release
2. run the macOS signing
3. replace the macOS artifacts in the jamulussoftware/jamulus Github release with the signed ones
4. issue the release annoucement
5. update updatecheck1 and/or updatecheck2 with the release build

All of that lot needs to happen more or less "as soon as it can" in order. But everyone involved needs to know it's happening and where we are in that flow.

[hoffie]

All of that lot needs to happen more or less "as soon as it can" in order. But everyone involved needs to know it's happening and where we are in that flow.

Yep.

Regarding 3.9.1 again:
@pljones Could you do the SourceForge upload (I don't have access), post the announcement (you had already prepared it, I think) and update update02.jamulus.io? I can have a look at the remaining items tomorrow.

[pljones]

SourceForge upload

On its way.
EDIT: Done https://sourceforge.net/projects/llcon/files/Jamulus/3.9.1/

post the announcement

#2906

Still waiting for someone to confirm the website translators - I've not been able to mange to find out how. It's worth double-checking the contributors.

update update02.jamulus.io

Best after the annoucement, indeed, as it's more for those who don't read the announcement anyway.

[ann0see]

@pljones just for reference: https://hosted.weblate.org/projects/jamulus/#reports shows the translators

[pljones]

I don't see where you got that on the site. Plain text would be easier for editing the announcement.

[ann0see]

I think you need to be logged in.

* Italian

    * ignotus  (1)
    * Giuseppe <dzpex> (57)


* Korean

    * ignotus  (26)
    * 이정희  (586)


* French

    * Olivier Humbert <trebmuh> (237)
    * Julien Taverna <jujudusud> (322)


* Spanish

    * ignotus  (136)


* Dutch

    * Maarten (1)
    * Henk De Groot  (850)


* German
    * ann0see  (22)


* Portuguese (Brazil)

    * ignotus  (20)
    * gbonaspetti  (28)
    * Julia Palaretti  (55)
    * Melcon Moraes <melcon> (165)


* Portuguese

    * Melcon Moraes <melcon> (3)
    * gbonaspetti <gbonaspetti> (4)
    * 이정희  (6)
    * Manuela Silva  (205)

It doesn't seem to be filtered for the website only.

[comradekingu]

You need to be an admin to get those details too.

[ann0see]

You need to be an admin to get those details too.

Ok. Good to know. Thanks!

[pljones]

OK, for this release announcement we'll bundle app and website. That gives:

이정희
ann0see
gbonaspetti <gbonaspetti>
Giuseppe <dzpex>
Henk De Groot
ignotus
Julia Palaretti
Julien Taverna <jujudusud>
Maarten
Manuela Silva
Melcon Moraes <melcon>
Olivier Humbert <trebmuh>

[pljones]

Are all the website issues for 3.9.1 getting closed?

[ann0see]

Not yet. I think the translation period is not yet over?

[pljones]

Well, for 3.9.1 it is. Anything now is "after release".

[ann0see]

The website translation still has some time since it started a lot later than expected. So there will be a post release update.

[ann0see]

Website is now updated

[pljones]

@emlynmac @ann0see @gilgongo I've unpinned this and am about to close -- assuming there were no changes as an outcome of

Update this template in https://jamulus.io/contribute/Release-Process with any improvements if needed.

and

Determine if a release retrospective is needed, create on Discussions if required

[pljones]

OK, closing.

[ann0see]

The Mac stuff might need updating.

[pljones]

OK, we can have an issue targetting 3.10.0 if it does.