Release Checklist
Jump to navigation
Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
Mudlet release checklist
- 5 days before the release (14 if it's a long one)
- ☐ [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). - ☐ [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
development
intomaster
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.
- ☐ 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"