Release Checklist

Mudlet release checklist

1. 5 days before the release (14 if it's a long one)
   1. ☐ [automated] update mudlet.ts with the latest translations strings for translators to translate
   2. ☐ [automated] update mudlet_en_US.ts with the latest translation strings, translate/update the few plural forms it contains as necessary and then generate the binary translation mudlet_en_US.qm file and merge it into the repo (see Translating Mudlet - English (American) translation).
   3. ☐ [automated] update Geyser docs
   4. ☐ [automated] update built-in packages and scripts (IRE mapping script, ...)
   5. ☐ [automated] update edbee to latest in our fork, and the subsequent submodule
   6. ☐ merge outstanding approved pull requests
   7. ☐ update Patreon supporters in About tab
   8. ☐ create a new release-<version> branch off development
      1. everything above this step can be done concurrently.
   9. ☐ create the next milestone in github if it doesn't exist already
   10. ☐ go through every single commit (in main repo and installers) and ensure all new functionality is documented
   11. ☐ check all regressions to see if any must be fixed before the release
   12. ☐ go through every single commit and write up a relese post with the latest highlights - and save it as a github milestone draft
       1. everything above this step can be done concurrently, while 13, 14, and 15 below must be done sequentially.
   13. ☐ wait a day for PTBs to get built
   14. ☐ 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).
   15. ☐ get testers to sign off (via Discord reaction) that they tested the release and it is fine with them
       1. 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
2. on release day
   1. ☐ merge latest translations from Crowdin
   2. ☐ merge all Area 51 functions into main wiki
   3. ☐ purge Lua_Functions cache to ensure the latest functions are visible
   4. ☐ merge latest autocomplete json
      1. everything above this step can be done concurrently, while everything below this step must be done sequentially.
   5. ☐ 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>
   6. ☐ update mudlet.pro and CMakeLists.txt to new version and strip out BUILD to be empty in release branch (release process starts here)
   7. ☐ tag release in git and push
   8. ☐ manually create source code package following this
   9. ☐ reset BUILD in release branch to be -dev
   10. ☐ wait for the builds to complete...
   11. ☐ test that all binaries launch and work
   12. ☐ 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.
   13. ☐ manually link uploaded artifacts to dblsqd (see [1])
   14. ☐ update repo-metadata.yml to the next release version
   15. ☐ close current github milestone
   16. ☐ update downloads on mudlet.org
   17. ☐ [automated] create changelog with a github action
   18. ☐ create a proper github release using the draft created earlier
   19. ☐ [automated] insert list of translators into the release post (tool)
   20. ☐ [automated] insert list of coders into the release post (tool)
   21. ☐ publish release post and it will be automatically posted to mudlet.org on save
   22. ☐ delay rest of announcements until 3-4 days past the release; post when there are no verified issues in update
       1. everything above the step must be done sequentially, while everything below this step can be done concurrently.
   23. ☐ 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
   24. ☐ post news to https://launchpad.net/mudlet
   25. ☐ post news to opencollective https://opencollective.com/mudlet/updates
   26. ☐ post thread on forums.mudlet.org
   27. ☐ post update on achaea, starmourn, imperian, lusternia, pkuxkx.net, softpedia
   28. ☐ post update on twitter, reddit, http://arkadia.rpg.pl, muder.ru
   29. ☐ email to [email protected] about the update
   30. ☐ submit mudlet windows installer to avg and avast whitelisting
   31. ☐ update Linux distro maintainers, Chocolatey maintainer, flag package outdated on arch
   32. ☐ merge development into master branch
   33. ☐ 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.
   34. ☐ create a poll in Discord - yes/no/abstain - if people like the new update or no

[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"

Individual contributor TODOs

• keneanung: https://github.com/users/keneanung/projects/1
• vadi2: https://gist.github.com/vadi2/c4dd137010c1b969c011293eddfcee73