Release Checklist
Jump to navigation
Jump to search
Mudlet release checklist
- 5 days before the release (14 if it's a long one)
- ☐ 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).
- ☐ [automated] update
mudlet.ts
with the latest translations strings for translators to translate - ☐ [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 translationmudlet_en_US.qm
file and merge it into the repo (see Translating Mudlet - English (American) translation). - ☐ merge outstanding approved pull requests
- ☐ create a new
release-<version>
branch offdevelopment
- ☐ go through every single commit (in main repo and installers) and ensure all new functionality is documented
- ☐ update http://www.mudlet.org/geyser/files/index.html (need to document how to upload)
- ☐ [automated] update built-in packages and scripts (IRE mapping script, ...)
- ☐ [automated] update edbee to latest in our fork, and the subsequent submodule
- ☐ update Patreon supporters in About tab
- ☐ check all regressions to see if any must be fixed before the release
- ☐ 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
- ☐ go through every single commit and write up a newspost with the latest highlights
- on release day
- ☐ 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>
- ☐ 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
- ☐ 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
- ☐ manually create source code package following this
- ☐ reset BUILD in release branch to be -dev
- ☐ wait for the builds to complete...
- ☐ 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]:
- ☐ test that all binaries launch and work
- ☐ create the next milestone in github
- ☐ 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
- ☐ make a proper github release (it will be automatically posted to mudlet.org on publish)
- ☐ delay rest of announcements until 3-4 days past the release; post when there are no verified issues in update
- ☐ post news to https://launchpad.net/mudlet
- ☐ 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
- ☐ merge
development
intomaster
branch - ☐ update Linux distro maintainers, Chocolatey maintainer, flag package outdated on arch (release process ends here)
- ☐ 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
- ☐ 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:
[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"