Map release processes interacting

[Kebap]

Brief summary of issue / Description of requested feature:

To help automate releases, some steps have been automated already.
To better integrate the steps now map their dependencies, orders, etc.

Steps to reproduce the issue / Reasons for adding feature:

1. Read https://wiki.mudlet.org/w/Release_Checklist for a glimps of which steps are necessary in total
2. The points listed there seem to imply a linear order: Do step 2 after step 1 but before step 3, etc. Etc.
3. In reality, many of the points could probably be done in arbitrary order, or be started at a same time in parallel, etc.

Expected result of feature

• Clear up dependencies: Which steps do really need to follow after which other steps?
• Clear up inputs: Which steps rely on information given or gathered in other steps? Can the information be stored throughout?
• Clear up outputs: Which results do we want to archieve in the end? Which are mere steps on the way and subject to change?

Extra information, such as the Mudlet version, operating system and ideas for how to solve / implement:

• I have started to actually paint a map of the process but need more input from release technicians

[Kebap]

The list in wiki consists of 2 big batches of steps. They seem to imply chronological order alright:

• The first batch is "preparation" days before release, and will be discussed in this comment.
• The second batch describes the "actual" day of release. See next comment for more details.

Preparation happens 5 days before the release (14 if it's a long one)

1. announce start of testing in Discord channel #mudlet-testing
   1.1 prepare a list of additions/improvements/fixes (but not infrastructure),
   1.2. prepare links to latest download builds (from Latest Branch Snapshots,
   1.3. double check that sha matches the latest commit).
   1.4. post to Discord
2. [automated] update mudlet.ts with the latest translations strings for translators to translate
3. [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).
4. merge outstanding approved pull requests
5. create a new release- branch off development
6. go through every single commit (in main repo and installers) and ensure all new functionality is documented
7. [automated] update Geyser docs
8. [automated] update built-in packages and scripts (IRE mapping script, ...)
9. [automated] update edbee to latest in our fork, and the subsequent submodule
10. update Patreon supporters in About tab
11. check all regressions to see if any must be fixed before the release
12. 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
13. go through every single commit and write up a newspost with the latest highlights

Which of these steps can be started at the same time, or even before the step number 1?
Which do really need to happen after another step has actually completed before them?

For example, step 5 seems to change a central thing, it creates an actual new branch in git.
Therefore, some of the following steps may need to work on this branch, and can't do it before.
However none of the steps explicitly says so. Obviously, this is a brief checklist written for folks who know the details.
I assume the steps 7, 8, 9, 10 actually must happen after step 5, and happen in the new branch?

For example, steps 4 and 6 and 11 seem like they should actually happen before step 1, as they may require additional testing.

What is more, step 1.1. and steps 6 and 13 all seem based on the same list of commits. Am I right?
Maybe we can find a way to just traverse this list once, and add additional info once, and use and improve it each time?

Let's try to list the prerequisites in a more structured way. When can each step really already start?

1. at the START? Or after 4? 6? 11?
2. after START
3. after 2
4. after START
5. after 4?
6. after START
7. after 5?
8. after 5?
9. after 5?
10. after 5?
11. after START?
12. after a few days of delay after 1
13. after START

[Kebap]

"Actual" release on release day:

1. 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 ". See the changelog." <version, ie 4.11.0>
2. merge latest translations from Crowdin
3. merge all Area 51 functions into main wiki
4. purge Lua_Functions cache to ensure the latest functions are visible
5. merge latest autocomplete json
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 in git
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. 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.
12. manually link uploaded artifacts to dblsqd[1]:
13. test that all binaries launch and work
14. create the next milestone in github
15. update repo-metadata.yml to the next release version
16. close current github milestone
17. update downloads on mudlet.org
18. [automated] create changelog with a github action
19. create a proper github release
20. [automated] insert list of translators into the post (tool)
21. [automated] insert list of coders into the post (tool)
22. publish release post, it will be automatically posted to mudlet.org on save
23. delay rest of announcements until 3-4 days past the release; post when there are no verified issues in update
24. post to #announcements in Discord. Publish the post, then add a follow-up @everyone tag. This will notify folks in the Mudlet server without showing the @everyone tag in all other syncronised servers
25. post news to https://launchpad.net/mudlet
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. merge development into master branch
32. update Linux distro maintainers, Chocolatey maintainer, flag package outdated on arch (release process ends here)
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

Again trying to list, which step really needs to come after which prerequisite:

1. after START
2. after START
3. after START
4. after 3
5. after START
6. after 2 and 5
7. after 6
8. after 6
9. after 8
10. after 9
11. after 10
12. after 11 and 1
13. after 10, maybe even before 12?
14. after ?
15. after 14
16. after 14
17. after 13
18. after ?
19. after ?
20. after ? alongside 18
21. after ? alongside 18
22. after 18, 20, 21
23. after a few days of actual delay after 22, 19, 12?
24. after 23
25. after 23
26. after 23
27. after 23
28. after 23
29. after 23
30. after ?
31. after ?
32. after ?
33. after 31?
34. not required

[Kebap]

@vadi2 Could you kindly verify and comment the list of prerequisites of each step?

[vadi2]

Thanks for writing this up! I'll have a look.

[vadi2]

Answering everything in the issue would be rather slow so instead I updated the release checklist with clarifications on which steps must be sequential and which steps can be concurrent. Does it look good to you now?