feat: updated release procedure to be more up-to-date - #676
Conversation
…uest, using just generic role is better Co-authored-by: SlamBamActionman <83650252+SlamBamActionman@users.noreply.github.com>
|
|
||
| This needs to be done via PR on github (because the master branch is protected from pushing). | ||
| You can merge this PR by yourself immediately, but **DO NOT SQUASH IT**. | ||
| Add release version tag on commit that will be used for our new release. |
There was a problem hiding this comment.
in PR space-wizards/space-station-14#45690 i added tag thing to GHA so it will be merged with 'Run Publish' and workflow will get launch option for 'version'
| Before you start, probably make sure no one else is already on it. Lead Maintainers usually do the staging and there is *typically* no need for anyone not frequently taking part in the setup process to get involved. | ||
| Before process starts, 'Release captain' should be chosen. It is temporary informal role during this release, controlling execution of all release key steps. When the person is chosen - announce so in staff channel and tag @maintainers with message (can be done together with staging cutoff announcement), to ensure no one else is already on it. It is the Producer role team's responsibility to arrange who will be Release Captain. | ||
|
|
||
| 'Release captain' hat can be handed over for the rest of duration of release or just temporarily in case current 'captain' cannot fully operate due to any problems, having person who can properly dedicate time to release coordination is of most importance. |
There was a problem hiding this comment.
I get where you are coming from, but at the same time we can't expect a single person to be constantly available between staging cutoff up to release, and then we might just be creating a more convoluted situation where available people try to figure out of anything needs to be done immediately or they should just wait for the overseer. Might it not be a better idea to assume from the first place that the process has to work with whoever is available at the time, and thus focus on making that potentially-async coordination between different people work?
There was a problem hiding this comment.
The problem is, async-coordination could be stretched indefinitely, which is bad for everyone involved, as we saw last release. There are situations where one person with full responsibility is better then ten who are not sure if they are making right call. Even if one person will not make right call SOMETIMES. This whole thing does not mean that everyone needs a head-pat from 'release captain' on any activity, it means that now there is role who will be asking timings and making decisions efficiently. Its a task of routing and organization, which is needed to do things well time-wise, and not stretching our releases is pretty important for all the reasons.
There was a problem hiding this comment.
I'm perhaps not the most qualified for this, but I gave it a grammar pass
I also have some more specific comments, I always kept those separate from change suggestions so you should be good to just click through the suggestions (if you accept), and then see what remains and discuss those
| > It is up to 'Release captain' to choose if problem fixes worth additional time until release, but as a general rule it should be noted that complex/heavy fixes are undesirable (highly discouraged), as 'staging' branch does not have any testing grounds. | ||
|
|
||
| ## The Release | ||
| ## The Release (timinig depends on 'when its ready'™) |
There was a problem hiding this comment.
This phrasing is kinda at odds with the fact that we are stating above that the default release time is Sunday 21:00, even when it's understood that it may be delayed pending hotfixes
| If there are merge conflicts at this step, note that you could publish stable before you get bogged down fixing the conflict for master so meanwhile the publish tests can run. | ||
|
|
||
|
|
||
| ### 5. Monitor if Salamander actually gets the new release after their next restart |
There was a problem hiding this comment.
This might no longer be an issue? We now have the servers on different hardware at different providers
There was a problem hiding this comment.
This is part of release procedure because unless players get new version, its not done yet :) so i think it should stay. Or were you asking about something else?
There was a problem hiding this comment.
I meant monitoring Salamander, specifically. It was singled out, because, as per the detailed steps below, Salamander used to sometimes mysteriously not get the update until restarted multiple times
There was a problem hiding this comment.
I mean, there should be server notification about next round, its worth at least checking that we got that, sitting until it actually gets updated might be a bit too much.
Errant fixed my typos Co-authored-by: Errant <35878406+Errant-4@users.noreply.github.com>
Errant fixed my typos Co-authored-by: Errant <35878406+Errant-4@users.noreply.github.com>
Errant fixed my typos Co-authored-by: Errant <35878406+Errant-4@users.noreply.github.com>
Errant fixed my typos Co-authored-by: Errant <35878406+Errant-4@users.noreply.github.com>
Errant fixed my typos Co-authored-by: Errant <35878406+Errant-4@users.noreply.github.com>
Errant fixed my typos Co-authored-by: Errant <35878406+Errant-4@users.noreply.github.com>
Errant fixed my typos Co-authored-by: Errant <35878406+Errant-4@users.noreply.github.com>
Errant fixed my typos Co-authored-by: Errant <35878406+Errant-4@users.noreply.github.com>
Errant fixed my typos Co-authored-by: Errant <35878406+Errant-4@users.noreply.github.com>
Errant fixed my typos Co-authored-by: Errant <35878406+Errant-4@users.noreply.github.com>
Errant fixed my typos Co-authored-by: Errant <35878406+Errant-4@users.noreply.github.com>
Errant fixed my typos Co-authored-by: Errant <35878406+Errant-4@users.noreply.github.com>
Errant fixed my typos Co-authored-by: Errant <35878406+Errant-4@users.noreply.github.com>
Errant fixed my typos Co-authored-by: Errant <35878406+Errant-4@users.noreply.github.com>
|
Gonna add Discourse topic for better back-and-forth navigation. |
4 participants
Updated release procedure, introduced 'Release captain' role (poor naming, ready to hear opinions), fixed maints meeting template and created release chechlist in outline.