Release Checklist

From Mudlet
Revision as of 04:43, 2 July 2019 by Vadi (talk | contribs) (Mentioning that we're not using a default option because it is the default isn't super helpful)
Jump to navigation Jump to search

Mudlet release checklist

  1. 5 days before the release
    1. ☐ update mudlet.ts with the latest translations strings for translators to translate (using Q 5.12.2+ lupdate ./src/ -ts ./translations/mudlet.ts)
    2. ☐ 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. ☐ merge outstanding approved pull requests
    4. ☐ create a new release-<version> branch off development
    5. ☐ go through every single commit and ensure all new functionality is documented
    6. ☐ update (need to document how to upload)
    7. ☐ update built-in packages and scripts
    8. ☐ update edbee to latest
    9. ☐ go through every single commit and write up a newspost with the latest highlights
  2. on release day
    1. ☐ create a new release in dblsqd
    2. ☐ merge latest translations from Crowdin
    3. ☐ merge latest autocomplete json
    4. ☐ update and CMakeLists.txt to new version and strip out BUILD to be empty in release branch (release process starts here)
    5. ☐ tag in git
    6. ☐ reset BUILD in release branch to be -dev
    7. ☐ test that all binaries launch and work
    8. ☐ close github milestone
    9. update downloads on
    10. ☐ post news on - for all languages
    11. ☐ Create Quick Redirect like
    12. ☐ post news to
    13. ☐ make a proper github release (use turndown to convert release post html to markdown)
    14. ☐ post thread on
    15. ☐ post update on achaea, starmourn, imperian,, forums, softpedia
    16. ☐ post update on twitter,, reddit,, torilmud,
    17. ☐ email to about the update
    18. ☐ submit mudlet windows installer to avg and avast whitelisting
    19. ☐ merge, don't squash or rebase, the release branch into development (ensure -dev suffix is present)
    20. ☐ merge development into master branch
    21. ☐ update Linux distro maintainers, flag package outdated on arch (release process ends here)

Individual contributor TODOs