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-com
create a new branch release-X-Y
from master
.release-X-Y
branch, 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.md
by copying the
monthly release blog template.release-X-Y
branch, create the release post data directory, to which features and other data will be added:
X_Y
in the data/release_posts
directory.data/release_posts/unreleased/samples/mvp.yml
into data/release_posts/X_Y/mvp.yml
.sites/uncategorized/source/includes/home/ten-oh-announcement.html.haml
changing 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-Y
and the target branch master
.Draft: Release post - GitLab X.Y
. Prefix the title with Draft:
.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-com
project, create 3 new
branches from master: one for bugs, one for usability improvements, and one for performance improvements.
Name the branches release-X-Y-bugs
release-X-Y-usability-improvements
and release-X-Y-performance-improvements
.Draft: release-X-Y-bugs
, Draft: release-X-Y-usability-improvements
, and
Draft: release-X-Y-performance-improvements
, and use the
Release-Post-Bug-Usability-PerformanceImprovement-Block
.
template.release post
release post item
Technical Writing
@mentions
with the actual task owner names.release-X-Y-bugs
branch, add a new file to the data/release_posts/unreleased/
folder called bugs.yml and populate it with the content of bugs.yml
release-X-Y-usability-improvements
branch, 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-post-ux-improvements.yml
.release-X-Y-performance-improvements
branch, add
a new file to the data/release_posts/unreleased/
folder called performance_improvements.yml and populate it with the content of performance_improvements.yml
.Release Post X.Y Retrospective
as 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.