Difference between revisions of "Release Checklist"

From Mudlet
Jump to navigation Jump to search
 
(100 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 
= Mudlet release checklist =
 
= Mudlet release checklist =
−
# ☐ ensure windows, mac, linux generic installers and the ubuntu ppa are good to go
+
# 5 days before the release (14 if it's a long one)
−
# ☐ go through every single commit and ensure all new functionality is documented
+
## ☐ [automated] update <code>mudlet.ts</code> with the latest translations strings for translators to translate
−
# ☐ update http://www.mudlet.org/geyser/files/index.html (need to document how to upload)
+
## ☐ [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]).
−
# ☐ update built-in packages and scripts
+
## ☐ [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, ...)
−
# ☐ update src.pro and CMakeLists.txt to new version and strip out BUILD to be empty in development branch
+
## ☐ [automated] update edbee to latest in our fork, and the subsequent submodule
−
# ☐ tag in git (release process starts here)
+
## ☐ merge outstanding approved pull requests
−
# ☐ merge latest development to master branch
+
## ☐ update Patreon supporters in About tab
−
# ☐ make windows installer
+
## ☐ create a new <code>release-<version></code> branch off <code>development</code>
−
# ☐ make linux installers
+
### everything above this step can be done concurrently.
−
# ☐ update Ubuntu PPA
+
## ☐ create the next milestone in github if it doesn't exist already
−
# ☐ reset BUILD in development branch to be -dev
+
## ☐ go through every single commit (in main repo and installers) and ensure all new functionality is documented
−
# ☐ post news on mudlet.org
+
## ☐ 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 to https://launchpad.net/mudlet
+
## ☐ go through every single commit and write up a relese post with the latest highlights - and save it as a github milestone draft
−
# ☐ make a proper github release
+
### everything above this step can be done concurrently, while 13, 14, and 15 below must be done sequentially.
−
# ☐ post thread on forums.mudlet.org
+
## ☐ wait a day for PTBs to get built
−
# ☐ post update on achaea, lusternia, imperian, dsl-mud.org, mudconnect.com, topmudsites.com forums, [http://linux.softpedia.com/get/GAMES-ENTERTAINMENT/MUD/Mudlet-45973.shtml softpedia]
+
## ☐ 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 twitter, reddit, http://arkadia.rpg.pl
+
## ☐ get testers to sign off (via Discord reaction) that they tested the release and it is fine with them
−
# ☐ update Linux distro maintainers, flag package outdated on arch (release process ends here)
+
### 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
 +
## ☐ 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 [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.
 +
## ☐ [https://www.mudlet.org/2021/10/trial-pay-out-to-popular-prs/ 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"
  
−
= Post 3.0 checklist =
 
−
# ☑ merge release_30 into development and remove the branch (see https://github.com/Mudlet/Mudlet/pull/367 for some period discussion): http://wiki.mudlet.org/w/The_Merge
 
−
# ☑ migrate the project from launchpad.net to github.com (help wanted)
 
−
# ☑ merge release_31 into development and remove the branch: http://wiki.mudlet.org/w/The_Merge
 
−
# ☑ move vadi2/mudlet-lua into main tree (https://github.com/Mudlet/Mudlet/pull/832)
 
−
# apply clang-format to all files
 
−
# enforce clang-format on commit & pr acceptance
 
−
# upgrade mudlet.org linode image (help wanted)
 
−
# in general, 4.0 is about i18n support - but as always, feel free to work on whatever interests you
 
−
# (From SlySven): unify exit "directions" into single QPair<quint8,QString> item {Existing DirCodeNumber + 13 for special exits, QString() for normal/QString("special exit name") for special exits} - makes it possible to streamline TRoom class and helps for I18n as we can drop NLS {Native Language Support} strings in for directions 1-12 if needed...!
 
−
# (From SlySven): Revamp 2D mapper:   
 
−
#* use "stub" out to 0.5x inter-room distance for all actual orthogonal/diagonal exits and draw exit lines from end of there to corresponding opposite exit in destination room (if present)/reverse exit in destination room (otherwise)/center of exit room (fallback).  Choosing to call this "Z" exits to reflect east exit from one room going to west exit in second room where the first room is north of the second.
 
−
#* add drawing support for doors on stub exits/custom lines
 
−
#* add stub special exits (for those odd exits which you do no yet know where they go) together with room indications for (at least) one of such things being present and also indication of a special exit without a custom exit line representation (again to show presence of such a thing).
 
−
# (From SlySven): Revamp 3D mapper:
 
−
#* port away from deprecated QGLWidget usage (it'll cause us less [https://bugreports.qt.io/browse/QTBUG-39210?focusedCommentId=267859&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-267859 issues on mac] too)
 
−
#* rewrite code to use modern (indirect) OpenGL 3.0+ - would be needed to port to OpenGLES (e.g. Raspberry Pi) platforms anyway.
 
−
#* generally clean up the 3D paintGL() code - it is rather messy at present with redundant/ineffective calls.
 
  
 
= Individual contributor TODOs =
 
= Individual contributor TODOs =
−
https://gist.github.com/keneanung/0d8def8454c912f28842d3749ad65f00
+
* keneanung: https://github.com/users/keneanung/projects/1
−
https://gist.github.com/vadi2/1fb249c48dead71b9641f840622e8495
+
* vadi2: https://gist.github.com/vadi2/c4dd137010c1b969c011293eddfcee73
 +
 
 +
[[Category: Mudlet Admin Manual]]

Latest revision as of 06:49, 1 February 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. ☐ 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 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 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"


Individual contributor TODOs

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