Prepare release 3.7.0

[hoffie]

• Decide if this should be a bugfix release (e.g. 3.6.2 -> 3.6.3) or a feature release (3.6.2 -> 3.7.0). -> We have a feature release, so it's 3.7.0
• Create a milestone and add all relevant issues (@ann0see did this)
• Ensure that all issues/PR targeted for this release are done by checking the milestone
• Declare a code freeze. PRs can still be worked on and may get reviewed, but must not be merged unless agreed explicitly.
• Create at least one beta release (@ann0see did that). WARNING: Do not deploy beta releases to the central server which is used for update checks.
• Get feedback on the stability of the beta release (@pljones and @hoffie are running servers and/or clients on the beta level)
• Website translations
  • Create new branch translate3_7_0 based on branch release (@ann0see did this)
  • Squash-merge changes into translate3_7_0
  • Ping translators. Translators should open PRs with their changes against the translate3_7_0 branch (?) and reference this issue ("Add German translations for 3.7.0")
  • Wait for all PRs to be merged
  • Merge translate3_7_0 into release
• App installer translations
  • Ping translators. @ann0see has done this individually?
  • Review PRs,
    Checklist for the PRs

    - [ ] Translator listed in the `src/util.cpp` **optionally add link to PR or code**
    - [ ] Looks consistent
    - [ ] Passes `tools/check-wininstaller-translations.sh`
    

  • Wait for all PRs to be merged:
    • pl Polish translation of Windows installer NSIS script #1124
    • fr Create fr.nsi #1125
    • es Updated Spanish translation #1152
• App translations (@softins handles this currently, https://github.com/orgs/jamulussoftware/teams/translators/discussions/6/comments/4)
  • Generate .ts files in master via lupdate (@softins, directly in master)
  • Ping translators (@softins). Translators do their work using linguist and submit PRs with their changes against master. Get the list of translators from src/utils.cpp (some grep/sed would be nice; last one per language is the active one).
  • Review PRs,
    Checklist for the PRs

    - [ ] Translator listed in the `src/util.cpp` **optionally add link to PR or code**
    - [ ] Punctuation and spacing consistent
    - [ ] Signal words consistent ("ASIO", "Buffer")
    - [ ] No untranslated strings (`grep unfinished -5 src/res/translation/translation_$TRANSLTION*.ts`)
    - [ ] Only a single `.ts` file checked in
    

  • Wait for all PRs to be merged:
    • de_DE V370 german #1097
    • es_ES Updated Spanish translation #1152
    • fr_FR Update translation_fr_FR.ts for 3.7.0 Release #1113
    • it_IT IT Update for 3.7.0 #1112
    • nl_NL Update Dutch translation for 3.7.0 (see #1086) #1110
    • pl_PL Updated Polish translation for 3.7.0 release #1099
    • pt_BR Update pt_BR translation for 3.7.0 (see jamulussoftware#1086) #1141
    • pt_PT Update pt_PT translation #1168 pt_PT translation of wininstaller for 3.7.0 #1208
    • sk_SK Update Slovak translation #1104
    • sv_SE Prepare Swedish translation för V370 #1106
  • Generate .qm files via lrelease Jamulus.pro
• Tag a release candidate
• Draft an announcement, include all contributors via tools/get_release_contributors.py (Draft 3.7.0 release announcement [don't merge!] #1223)
• Update the version number in Jamulus.pro and add the release date to the Changelog header and commit
• Tag this commit as r3_7_0
• Prepare Jamulus.pro (dev suffix) and ChangeLog (add a header) for the next release
• Wait for the build to complete
• Do a smoke test for Windows/Mac/Linux -- Do the binaries start/connect properly?
• Upload the artifacts to SourceForge and link latest
• Trigger the update notification by updating the Old Default Central Server
• Announce the new release with a summary of changes (+ link to the changelog for details), a link to the download page
  • On Sourceforge? (only if it has been done in the past?)
  • On Github discussions? (An "Announcements" sub-form maybe?)
  • On Facebook in the group "Jamulus (official group)"
• Update download links on the website (start page, per-platform pages + translations) Add Download links for 3.7.0 jamuluswebsite#359
• Update this checklist with any improvements which were found

---

As this is the first time we use such an checklist

• Decide where to keep the release checklist:
  • Option 1: Make it an issue template. Would make it simple for us, but could be confusing for non-developers.
  • Option 2: Add it to the Wiki
• Should one part of the checklist live in the website repo?

Please feel free to edit/extend this issue description! Just trying to document what needs to be done as we move along.

[ann0see]

Update the version number in Jamulus.pro and commit

After this commit, the version entry to the changelog has to be created.

See the commit history and look for "Prepare for next release"

[pljones]

There's something missing.

In order to trigger the update notification, the (old) "Default Central Server" needs updating, doesn't it? That should happen just after publishing the artifacts (from the published artifact for the platform, ideally).

(However it's done, a clear step of "Trigger the update notification" should be added.)

[gilgongo]

I think the website translation steps make sense to me now. I guess at the end of the process we delete the translation branch?

[atsampson]

It might be a good idea to explicitly add "Test the generated artifacts" before "Upload the artifacts to Sourceforge" - i.e. check that the source tarballs are buildable on a real system, and that the binaries can at least start up and connect to a server.

The CI tests will catch some types of errors, but they won't detect problems in the artifact generation process itself, and I've seen plenty of examples over the last few years of projects shipping broken release artifacts when their CI passed (e.g. because the generation process was missing some files, or there was something broken about the tools or libraries in the automated build environment).

[pljones]

at least start up and connect to a server.

... and that we won't break the directory servers when the build gets deployed to them.

[ann0see]

I guess at the end of the process we delete the translation branch?

@gilgongo

Yes. That’s what I think should happen.

[gilgongo]

OK, so are we good for squash merging changes into translate3_7_0? I think the only new feature for the docs was the --serverpublicip description which is done as far as I know. Do we need to write anything up for the --ctrlmidich syntax?

[hoffie]

@pljones @atsampson @ann0see @gilgongo Thanks for your comments, I have integrated all those suggestions.

OK, so are we good for squash merging changes into translate3_7_0?

I think yes, but I'm certainly not the most qualified to judge that.

Do we need to write anything up for the --ctrlmidich syntax?

If it changes existing syntax/compatibility, I'd say we must, if it's "only" an extension I'd say it's nice-to-have. Maybe @dakhubgit can help?

[pljones]

Do we need to write anything up for the --ctrlmidich syntax?

Existing syntax should continue to work but without the new features. The command line help documents the new syntax, I think the web site table got updated, too?

[gilgongo]

Yes it did by the looks of it. So I'd say we can merge for translation then. I'll do that this evening and message the translators.

[softins]

I have updated the .ts translation files for 3.7.0 and committed directly to master. As they are not code, and are automatically generated by lupdate, I didn't consider they needed review.

[gilgongo]

Just checking since this is the first time I've done this with all the tests running ... The "Only 65535 characters are allowed" remark-lint errors: can I ignore them?

[ann0see]

Yes, you can. I'd like to merge my PR before the translations of the website start.

[gilgongo]

@ann0see Oops I didn't see the second part of your message! Can you merge that to translation?