If the automated pipeline fails, the manual steps below can be done either locally or using the GitLab Web IDE:
gitlab.com/gitlab-com/www-gitlab-comcreate a new branch
release-X-Ybranch, create the blog post file, containing the introduction and the blog post frontmatter information:
sites/uncategorized/source/releases/posts/directory, add a new file called
YYYY-MM-22-gitlab-X-Y-released.html.mdby copying the monthly release blog template.
release-X-Ybranch, create the release post data directory, to which features and other data will be added:
sites/uncategorized/source/includes/home/ten-oh-announcement.html.hamlchanging all the GitLab version numbers and URLs referencing the release post to reflect the current one. Leave the announcement description as is, as you (the Release Post Manager) will change this later in the process.
Create a merge request with the introductory changes after the previous post has been merged and before the feature freeze date to make the post available to receive contributions from the team:
release-X-Yand the target branch
Draft: Release post - GitLab X.Y. Prefix the title with
Use the release post template for your MR.
Now that you have created the release post MR, refer to the checklist in the MR for each action that you need to take and the due dates of each action. Keep in mind the MRs for usability improvements, bugs, and performance improvements have their own checklists to be completed, including a task for the Release Post Manager to merge these MR by the 17th prior to final content assembly.
Create dedicated MRs from the sample templates for these content blocks (usability improvements, bugs, performance improvements). This separation from the main Release Post MR simplifies the contribution and discussion process.
Note for people adding content: The MRs for usability improvements, bugs, and performance improvements provide a place for others to add their content. While the Release Post Manager isn't responsible for creating the content, they are responsible for completing the tasks assigned to them in the checklist of the templates for these MRs, on schedule. Make sure to immediately apply any suggestion you make to avoid race conditions where your suggestion is considered as applied if someone else has directly pushed a commit (example). The TW lead will review the changes anyway, so no need to ask for a pre-review.
gitlab.com/gitlab-com/www-gitlab-comproject, create 3 new branches from master: one for bugs, one for usability improvements, and one for performance improvements. Name the branches
Draft: release-X-Y-usability-improvements, and
Draft: release-X-Y-performance-improvements, and use the
release post item
@mentionswith the actual task owner names.
release-X-Y-bugsbranch, add a new file to the
data/release_posts/unreleased/folder called bugs.yml and populate it with the content of
release-X-Y-usability-improvementsbranch, add a new file to the
data/release_posts/unreleased/folder called release-post-ux-improvements.yml and populate it with the content of
release-X-Y-performance-improvementsbranch, add a new file to the
data/release_posts/unreleased/folder called performance_improvements.yml and populate it with the content of
Release Post X.Y Retrospectiveas a title.
Note: After you have created the release post MR and all the related files, refer to the checklist in the MR for each action that you need to take and the due dates of each action. Keep in mind the MRs for usability improvements, bugs, and performance improvements have their own checklists to be completed, including a task for the Release Post Manager to merge these MR by the 17th prior to final content assembly.