Difference between revisions of "Release Checklist"
Jump to navigation
Jump to search
| (5 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
= Mudlet release checklist = | = Mudlet release checklist = | ||
# 5 days before the release (14 if it's a long one) | # 5 days before the release (14 if it's a long one) | ||
| − | |||
## ☐ [automated] update <code>mudlet.ts</code> with the latest translations strings for translators to translate | ## ☐ [automated] update <code>mudlet.ts</code> with the latest translations strings for translators to translate | ||
## ☐ [automated] update <code>mudlet_en_US.ts</code> with the latest translation strings, translate/update the few plural forms it contains as necessary and then generate the binary translation <code>mudlet_en_US.qm</code> file and merge it into the repo (see [https://wiki.mudlet.org/w/Translating_Mudlet#English_.28American.29_translation Translating Mudlet - English (American) translation]). | ## ☐ [automated] update <code>mudlet_en_US.ts</code> with the latest translation strings, translate/update the few plural forms it contains as necessary and then generate the binary translation <code>mudlet_en_US.qm</code> file and merge it into the repo (see [https://wiki.mudlet.org/w/Translating_Mudlet#English_.28American.29_translation Translating Mudlet - English (American) translation]). | ||
| + | ## ☐ [automated] update [http://www.mudlet.org/geyser/files/index.html Geyser docs] | ||
| + | ## ☐ [automated] update built-in packages and scripts (IRE mapping script, ...) | ||
| + | ## ☐ [automated] update edbee to latest in our fork, and the subsequent submodule | ||
## ☐ merge outstanding approved pull requests | ## ☐ merge outstanding approved pull requests | ||
| + | ## ☐ update Patreon supporters in About tab | ||
## ☐ create a new <code>release-<version></code> branch off <code>development</code> | ## ☐ create a new <code>release-<version></code> branch off <code>development</code> | ||
| + | ### everything above this step can be done concurrently. | ||
| + | ## ☐ create the next milestone in github if it doesn't exist already | ||
## ☐ go through every single commit (in main repo and installers) and ensure all new functionality is documented | ## ☐ go through every single commit (in main repo and installers) and ensure all new functionality is documented | ||
| − | |||
| − | |||
| − | |||
| − | |||
## ☐ check all [https://github.com/Mudlet/Mudlet/issues?q=is%3Aissue+is%3Aopen+label%3Aregression regressions] to see if any must be fixed before the release | ## ☐ check all [https://github.com/Mudlet/Mudlet/issues?q=is%3Aissue+is%3Aopen+label%3Aregression regressions] to see if any must be fixed before the release | ||
| + | ## ☐ go through every single commit and write up a relese post with the latest highlights - and save it as a github milestone draft | ||
| + | ### everything above this step can be done concurrently, while 13, 14, and 15 below must be done sequentially. | ||
| + | ## ☐ wait a day for PTBs to get built | ||
| + | ## ☐ after the PTBs have been built, announce start of testing in Discord channel #mudlet-testing with the list of additions/improvements/fixes (but not infrastructure), and add link to latest download builds (from [https://make.mudlet.org/snapshots Latest Branch Snapshots], but double check that sha matches [https://github.com/Mudlet/Mudlet/commits/development the latest commit]). | ||
## ☐ get testers to sign off (via Discord reaction) that they tested the release and it is fine with them | ## ☐ get testers to sign off (via Discord reaction) that they tested the release and it is fine with them | ||
### if a tester doesn't sign off for 2 releases, notify them, if they don't do it on the next one, remove them from the testers team | ### if a tester doesn't sign off for 2 releases, notify them, if they don't do it on the next one, remove them from the testers team | ||
| − | |||
# on release day | # on release day | ||
| − | |||
## ☐ merge latest translations from Crowdin | ## ☐ merge latest translations from Crowdin | ||
## ☐ merge all Area 51 functions into main wiki | ## ☐ merge all Area 51 functions into main wiki | ||
## ☐ [https://wiki.mudlet.org/w/Manual:Lua_Functions?action=purge purge] Lua_Functions cache to ensure the latest functions are visible | ## ☐ [https://wiki.mudlet.org/w/Manual:Lua_Functions?action=purge purge] Lua_Functions cache to ensure the latest functions are visible | ||
## ☐ merge [[Update_lua_function_list|latest autocomplete json]] | ## ☐ merge [[Update_lua_function_list|latest autocomplete json]] | ||
| + | ### everything above this step can be done concurrently, while everything below this step must be done sequentially. | ||
| + | ## ☐ create a new release in the 'release' channel in [https://www.dblsqd.com/user/apps/30a30c47-b1cd-48fe-b93e-ab9041b88323 dblsqd]. Make sure to enter the changelog right away, as it cannot be edited after. Include the full version number and a link to the release post ([[Media:Creating a new Mudlet release.png|example]]). A [https://www.npmjs.com/package/dblsqd-cli command-line variant] of this is: <code>dblsqd release -a mudlet -c release -m "<message>. <a href="https://mudlet.org/4-##">See the changelog</a>." <version, ie 4.11.0></code> | ||
## ☐ update mudlet.pro and CMakeLists.txt to new version and strip out BUILD to be empty in release branch (release process starts here) | ## ☐ update mudlet.pro and CMakeLists.txt to new version and strip out BUILD to be empty in release branch (release process starts here) | ||
| − | ## ☐ tag in git | + | ## ☐ tag release in git and push |
## ☐ manually create source code package [https://github.com/Mudlet/Mudlet/blob/33ad832253d6b6411d7c1132e68455742157d60d/CI/travis.linux.after_success.sh#L144 following this] | ## ☐ manually create source code package [https://github.com/Mudlet/Mudlet/blob/33ad832253d6b6411d7c1132e68455742157d60d/CI/travis.linux.after_success.sh#L144 following this] | ||
## ☐ reset BUILD in release branch to be -dev | ## ☐ reset BUILD in release branch to be -dev | ||
## ☐ wait for the builds to complete... | ## ☐ wait for the builds to complete... | ||
| + | ## ☐ test that all binaries launch and work | ||
## ☐ manually upload artifacts to https://www.mudlet.org/wp-content/files/?C=M;O=D through webmin. Linux and macOS ones will be available as artifacts on the Github job, while Windows is an artifact on the Appveyor job. | ## ☐ manually upload artifacts to https://www.mudlet.org/wp-content/files/?C=M;O=D through webmin. Linux and macOS ones will be available as artifacts on the Github job, while Windows is an artifact on the Appveyor job. | ||
| − | ## ☐ manually link uploaded artifacts to dblsqd[1] | + | ## ☐ manually link uploaded artifacts to dblsqd (see [1]) |
| − | |||
| − | |||
## ☐ update [https://github.com/Mudlet/Mudlet/blob/development/.github/repo-metadata.yml repo-metadata.yml] to the next release version | ## ☐ update [https://github.com/Mudlet/Mudlet/blob/development/.github/repo-metadata.yml repo-metadata.yml] to the next release version | ||
## ☐ close current github milestone | ## ☐ close current github milestone | ||
## ☐ [[Howto:Update Downloads|update downloads on mudlet.org]] | ## ☐ [[Howto:Update Downloads|update downloads on mudlet.org]] | ||
## ☐ [automated] create changelog with [https://github.com/Mudlet/Mudlet/actions/workflows/generate-changelog.yml a github action] | ## ☐ [automated] create changelog with [https://github.com/Mudlet/Mudlet/actions/workflows/generate-changelog.yml a github action] | ||
| − | ## ☐ | + | ## ☐ create a proper github release using the draft created earlier |
| + | ## ☐ [automated] insert list of translators into the release post ([https://www.mudlet.org/thank-translators/crowdin.php tool]) | ||
| + | ## ☐ [automated] insert list of coders into the release post ([https://github.com/Mudlet/Mudlet/actions/workflows/generate-coder-attribution.yml tool]) | ||
| + | ## ☐ publish release post and it will be automatically posted to mudlet.org on save | ||
## ☐ delay rest of announcements until 3-4 days past the release; post when there are no verified issues in update | ## ☐ delay rest of announcements until 3-4 days past the release; post when there are no verified issues in update | ||
| + | ### everything above the step must be done sequentially, while everything below this step can be done concurrently. | ||
| + | ## ☐ post to #announcements in Discord. Publish the post, then add a follow-up @everyone tag as a separate post. This will notify folks in the Mudlet server without showing the @everyone tag in all other syncronised servers | ||
## ☐ post news to https://launchpad.net/mudlet | ## ☐ post news to https://launchpad.net/mudlet | ||
| + | ## ☐ post news to opencollective https://opencollective.com/mudlet/updates | ||
## ☐ post thread on forums.mudlet.org | ## ☐ post thread on forums.mudlet.org | ||
## ☐ post update on achaea, starmourn, imperian, lusternia, pkuxkx.net, [http://linux.softpedia.com/get/GAMES-ENTERTAINMENT/MUD/Mudlet-45973.shtml softpedia] | ## ☐ post update on achaea, starmourn, imperian, lusternia, pkuxkx.net, [http://linux.softpedia.com/get/GAMES-ENTERTAINMENT/MUD/Mudlet-45973.shtml softpedia] | ||
| Line 42: | Line 52: | ||
## ☐ email to releaseradar@github.com about the update | ## ☐ email to releaseradar@github.com about the update | ||
## ☐ submit mudlet windows installer to avg and avast whitelisting | ## ☐ submit mudlet windows installer to avg and avast whitelisting | ||
| + | ## ☐ update Linux distro maintainers, [https://chocolatey.org/packages/mudlet/ContactOwners Chocolatey maintainer], flag package outdated on arch | ||
## ☐ merge <code>development</code> into <code>master</code> branch | ## ☐ merge <code>development</code> into <code>master</code> branch | ||
| − | |||
## ☐ merge, don't squash or rebase, the release branch into development (but don't delete right away, keep it around for a potential hotfix if needed. Delete after the next release is done). Do it right away so next day's PTB's versions is the new release. | ## ☐ merge, don't squash or rebase, the release branch into development (but don't delete right away, keep it around for a potential hotfix if needed. Delete after the next release is done). Do it right away so next day's PTB's versions is the new release. | ||
## ☐ [https://www.mudlet.org/2021/10/trial-pay-out-to-popular-prs/ create polls] for most popular changes | ## ☐ [https://www.mudlet.org/2021/10/trial-pay-out-to-popular-prs/ create polls] for most popular changes | ||
Latest revision as of 06:49, 1 February 2024
Mudlet release checklist
- 5 days before the release (14 if it's a long one)
- ☐ [automated] update
mudlet.tswith the latest translations strings for translators to translate - ☐ [automated] update
mudlet_en_US.tswith the latest translation strings, translate/update the few plural forms it contains as necessary and then generate the binary translationmudlet_en_US.qmfile and merge it into the repo (see Translating Mudlet - English (American) translation). - ☐ [automated] update Geyser docs
- ☐ [automated] update built-in packages and scripts (IRE mapping script, ...)
- ☐ [automated] update edbee to latest in our fork, and the subsequent submodule
- ☐ merge outstanding approved pull requests
- ☐ update Patreon supporters in About tab
- ☐ create a new
release-<version>branch offdevelopment- everything above this step can be done concurrently.
- ☐ create the next milestone in github if it doesn't exist already
- ☐ go through every single commit (in main repo and installers) and ensure all new functionality is documented
- ☐ check all regressions to see if any must be fixed before the release
- ☐ go through every single commit and write up a relese post with the latest highlights - and save it as a github milestone draft
- everything above this step can be done concurrently, while 13, 14, and 15 below must be done sequentially.
- ☐ wait a day for PTBs to get built
- ☐ after the PTBs have been built, announce start of testing in Discord channel #mudlet-testing with the list of additions/improvements/fixes (but not infrastructure), and add link to latest download builds (from Latest Branch Snapshots, but double check that sha matches the latest commit).
- ☐ get testers to sign off (via Discord reaction) that they tested the release and it is fine with them
- if a tester doesn't sign off for 2 releases, notify them, if they don't do it on the next one, remove them from the testers team
- ☐ [automated] update
- on release day
- ☐ merge latest translations from Crowdin
- ☐ merge all Area 51 functions into main wiki
- ☐ purge Lua_Functions cache to ensure the latest functions are visible
- ☐ merge latest autocomplete json
- everything above this step can be done concurrently, while everything below this step must be done sequentially.
- ☐ create a new release in the 'release' channel in dblsqd. Make sure to enter the changelog right away, as it cannot be edited after. Include the full version number and a link to the release post (example). A command-line variant of this is:
dblsqd release -a mudlet -c release -m "<message>. <a href="https://mudlet.org/4-##">See the changelog</a>." <version, ie 4.11.0> - ☐ update mudlet.pro and CMakeLists.txt to new version and strip out BUILD to be empty in release branch (release process starts here)
- ☐ tag release in git and push
- ☐ manually create source code package following this
- ☐ reset BUILD in release branch to be -dev
- ☐ wait for the builds to complete...
- ☐ test that all binaries launch and work
- ☐ manually upload artifacts to https://www.mudlet.org/wp-content/files/?C=M;O=D through webmin. Linux and macOS ones will be available as artifacts on the Github job, while Windows is an artifact on the Appveyor job.
- ☐ manually link uploaded artifacts to dblsqd (see [1])
- ☐ update repo-metadata.yml to the next release version
- ☐ close current github milestone
- ☐ update downloads on mudlet.org
- ☐ [automated] create changelog with a github action
- ☐ create a proper github release using the draft created earlier
- ☐ [automated] insert list of translators into the release post (tool)
- ☐ [automated] insert list of coders into the release post (tool)
- ☐ publish release post and it will be automatically posted to mudlet.org on save
- ☐ delay rest of announcements until 3-4 days past the release; post when there are no verified issues in update
- everything above the step must be done sequentially, while everything below this step can be done concurrently.
- ☐ post to #announcements in Discord. Publish the post, then add a follow-up @everyone tag as a separate post. This will notify folks in the Mudlet server without showing the @everyone tag in all other syncronised servers
- ☐ post news to https://launchpad.net/mudlet
- ☐ post news to opencollective https://opencollective.com/mudlet/updates
- ☐ post thread on forums.mudlet.org
- ☐ post update on achaea, starmourn, imperian, lusternia, pkuxkx.net, softpedia
- ☐ post update on twitter, reddit, http://arkadia.rpg.pl, muder.ru
- ☐ email to releaseradar@github.com about the update
- ☐ submit mudlet windows installer to avg and avast whitelisting
- ☐ update Linux distro maintainers, Chocolatey maintainer, flag package outdated on arch
- ☐ merge
developmentintomasterbranch - ☐ merge, don't squash or rebase, the release branch into development (but don't delete right away, keep it around for a potential hotfix if needed. Delete after the next release is done). Do it right away so next day's PTB's versions is the new release.
- ☐ create polls for most popular changes
[1]:
dblsqd push -a mudlet -c release -r "<release>" -s mudlet --type "standalone" --attach linux:x86_64 "https://www.mudlet.org/wp-content/files/Mudlet-<release>-linux-x64.AppImage.tar" dblsqd push -a mudlet -c release -r "<release>" -s mudlet --type "standalone" --attach mac:x86_64 "https://www.mudlet.org/wp-content/files/Mudlet-<release>.dmg" dblsqd push -a mudlet -c release -r "<release>" -s mudlet --type "standalone" --attach win:x86 "https://www.mudlet.org/wp-content/files/Mudlet-<release>-windows-installer.exe"