Difference between revisions of "Release Checklist"

From Mudlet
Jump to navigation Jump to search
 
(157 intermediate revisions by 5 users not shown)
Line 1: Line 1:
−
= New release checklist =
+
= Mudlet release checklist =
−
# update Mudlet/mudlet-lua with latest from vadi2/mudlet-lua
+
# 5 days before the release (14 if it's a long one)
−
# update http://www.mudlet.org/geyser/index.html
+
## ☐ [automated] update <code>mudlet.ts</code> with the latest translations strings for translators to translate
−
# update built-in packages and scripts
+
## ☐ [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]).
−
# tag in git
+
## ☐ [automated] update [http://www.mudlet.org/geyser/files/index.html Geyser docs]
−
# go through every single commit and write up a newspost with the latest highlights
+
## ☐ [automated] update built-in packages and scripts (IRE mapping script, ...)
−
## check wiki documentation while doing this to ensure everything is documented
+
## ☐ [automated] update edbee to latest in our fork, and the subsequent submodule
−
## document if not
+
## ☐ merge outstanding approved pull requests
−
# make windows installer
+
## ☐ update Patreon supporters in About tab
−
## sign windows installer
+
## ☐ create a new <code>release-<version></code> branch off <code>development</code>
−
# make macos installer
+
### everything above this step can be done concurrently.
−
# make linux installer
+
## ☐ create the next milestone in github if it doesn't exist already
−
# update Ubuntu PPA
+
## ☐ go through every single commit (in main repo and installers) and ensure all new functionality is documented
−
# regenerate geyser docs
+
## ☐ 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
−
# post news on mudlet.org
+
## ☐ go through every single commit and write up a relese post with the latest highlights - and save it as a github milestone draft
−
# post thread on forums.mudlet.org
+
### everything above this step can be done concurrently, while 13, 14, and 15 below must be done sequentially.
−
# post update on achaea, lusternia, imperian, dsl-mud.org forums (any others?)
+
## ☐ wait a day for PTBs to get built
−
# post update on twitter
+
## ☐ 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]).
−
# post update on facebook
+
## ☐ 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
 +
# on release day
 +
## ☐ merge latest translations from Crowdin
 +
## ☐ 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
 +
## ☐ 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)
 +
## ☐ 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]
 +
## ☐ reset BUILD in release branch to be -dev
 +
## ☐ wait for the builds to complete...
 +
## ☐ test that all binaries launch and work
 +
## ☐ [automated] ensure all artifacts have been uploaded to https://www.mudlet.org/all. Linux and macOS ones will be available as artifacts on the Github job, while Windows is an artifact on the Appveyor job.
 +
## ☐ [automated] 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
 +
## ☐ close current github milestone
 +
## ☐ [[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]
 +
## ☐ 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
 +
### 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, [http://linux.softpedia.com/get/GAMES-ENTERTAINMENT/MUD/Mudlet-45973.shtml 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, [https://chocolatey.org/packages/mudlet/ContactOwners Chocolatey maintainer], flag package outdated on arch
 +
## ☐ 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.
 +
## ☐ create a poll in Discord - yes/no/abstain - if people like the new update or no
  
−
= Post 3.0 checklist =
+
 
−
# merge release_30 into development and remove the branch
+
[1]:
−
# migrate the project from launchpad.net to github.com (help wanted)
+
 
−
# upgrade mudlet.org linode image (help wanted)
+
  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"
−
# add vadi2/mudlet-lua as a submodule to main tree
+
  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"
−
# merge release_31 into development and remove the branch
+
  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"
−
# apply clang-format to all files
+
 
−
# enforce clang-format on commit & pr acceptance
+
 
−
# work on 4.0 and add i18n support
+
= Individual contributor TODOs =
 +
* keneanung: https://github.com/users/keneanung/projects/1
 +
* vadi2: https://gist.github.com/vadi2/c4dd137010c1b969c011293eddfcee73
 +
 
 +
[[Category: Mudlet Admin Manual]]

Latest revision as of 09:20, 26 December 2024

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. ☐ [automated] ensure all artifacts have been uploaded to https://www.mudlet.org/all. Linux and macOS ones will be available as artifacts on the Github job, while Windows is an artifact on the Appveyor job.
    13. ☐ [automated] 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 releaseradar@github.com 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

Retrieved from "https://wiki.mudlet.org/index.php?title=Release_Checklist&oldid=22182"