-
Notifications
You must be signed in to change notification settings - Fork 240
Closed
Milestone
Description
- 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_0based on branchrelease(@ann0see did this) - Squash-merge
changesintotranslate3_7_0 - Ping translators. Translators should open PRs with their changes against the
translate3_7_0branch (?) and reference this issue ("Add German translations for 3.7.0") - Wait for all PRs to be merged
- Merge
translate3_7_0into release
- Create new branch
- 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:
- App translations (@softins handles this currently, https://github.com/orgs/jamulussoftware/teams/translators/discussions/6/comments/4)
- Generate
.tsfiles in master vialupdate(@softins, directly in master) - Ping translators (@softins). Translators do their work using
linguistand submit PRs with their changes against master. Get the list of translators fromsrc/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
.qmfiles vialrelease Jamulus.pro
- Generate
- 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.proand add the release date to the Changelog header and commit - Tag this commit as r3_7_0
- Prepare
Jamulus.pro(devsuffix) 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.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels
Type
Projects
Status
Done