Skip to content

Release post - GitLab 14.3

Nicole Schwartz requested to merge release-14-3 into master

QUICK JUMP TO A SECTION:

Overview

Process Improvements? Have suggestions for improving the release post process as we go? Capture them in the Retrospective issue.

Release post:

Related MRs:

Related files:

Release post branch ownership:

  • The Release Post Manager is solely in charge of changes to the release post branch. To avoid potential merge conflicts later during content assembly, it is imperative that Technical Writers do not merge updates from master to the release post branch even if it is falling behind or if there is a conflict. The Release Post Manager will take care of conflicts as part of the content assembly process on the 18th and work with the Technical Advisor as needed.

Handbook references:

People:

Release post manager Tech writer Technical Advisor Social Product Operations DRI
@NicoleSchwartz @kpaizee @oregand DRI: @wspillane & @social for Slack Checklist item @fseifoddini

Release post kickoff (@NicoleSchwartz)

Due date: 2021-09-07 (By the 7th) - Expand for Details

Before starting on this checklist, you should have created the release post branch and required files as explained in the Handbook

Note: Throughout the release post process, you'll do various Slack reminders/announcements. It is recommended you cc the Product Operations DRI and the rest of your release post team as you do these Slack posts because it helps keep everyone on the same page.

  • Prior to your first team standup consider setting up a coffee chat with the previous release post manager and/or Product Operations to ask for tips and any helpful "latest info"

  • After meeting with the previous release post manager and/or Product Operations for insights, consider setting up a meeting with your release post shadow to help them understand their role and how much capacity they have to support the work that month

  • Verify this MR is labeled ~"blog post" release release post priority1 and assigned to you (the Release Post Manager)

  • Add the current milestone to this MR

  • Create a release post retrospective issue by using the Release post retrospective template, and use Release Post 14.3 Retrospective as a title. Once created, update the link at the top of this MR description. Example retro issue.

    • Schedule a 50 min Live Retrospective meeting for some time after the 22nd. All action items for the retro need to be completed prior to the 1st of the next month in order to incorporate any process changes before the next release begins. Make sure to invite Product Ops to the Live Retro meeting. Product Ops will need to approve any major updates to the process identified during the Retrospective. 2021-09-30 1:00 am mountain

  • Replace each @mention in this MR description with the names of the Release Post Manager, Tech Writer, and Social Lead for this release

  • Update the links in this MR description

  • Update all due dates in this MR description

  • Make sure the release post branch has all initial files: sites/uncategorized/source/releases/posts/2021-09-22-gitlab-14-3-released.html.md, data/release_posts/14_3/mvp.yml and data/release_posts/14_3/cta.yml

  • Add the release number and your name as the author to sites/uncategorized/source/releases/posts/2021-09-22-gitlab-14-3-release.html.md

  • Per guidance on communication for the release, in #release-post channel in Slack, invite @kpaizee, @oregand and the release post manager shadow (whoever is running the next release post).

  • Update the topic in the #release-post channel:

    MR: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/89643
Preview page: https://about.gitlab.com/releases/gitlab-com/
Review App: https://release-14-3.about.gitlab-review.app/releases/2021/09/22/gitlab-14-3-released/
Retro issue: https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/12304

  • Announce yourself as the Release Post Manager in the #release-post channel, Technical Advisor, and TW lead as well for reference. cc Product Operations DRI

  • Set up a 15-minute weekly standup with the Technical Writer, and Tech advisor to touch base and troubleshoot. Invite the Product Operations DRI as well, as they will be your backup on all tasks should complications arise. If times zones conflict, this is not mandatory. Sample agenda

  • In the #release-post Slack channel, remind Product Managers that all content blocks (features, recurring, bugs, etc.) should be drafted, and under review by the 10th. All direction items and notable community contributions should be included in the release post.

  • Confirm your local dev environment is running a current version of Ruby. See Handbook section Local dev environment setup to run content assembly script.

  • Remind Technical Writer (either via slack or weekly standup) not to merge in changes from master to the release post branch. See the section Release post branch ownership above for more details.

Release post item creation reminders (@NicoleSchwartz)

**Due date: 2021-09-10** (By the 10th) - Expand for Details

Note: Throughout the release post-process, you'll do various Slack reminders/announcements. It is recommended you cc the Product Operations DRI and the rest of your release post team as you do these Slack posts because it helps keep everyone on the same page.

  • Remind the product managers in the #release-post channel that today is the day to have Release Post Items created and in review by the PMM and TW counterparts.
  • Remind the product managers in the #release-post channel that it's important we all follow the file naming guidelines as it affects the release post template as well as the release post teams ability to find release post items with ease.
  • Create the bugs, usability improvements and performance improvements MRs
    • Link these MRs to the top section of this MR so that they are easy to access
    • Inform EMs the bugs and performance improvement MRs are ready to receive their contributions by mentioning @gitlab-com/backend-managers and @gitlab-org/frontend/frontend-managers in the comments of this MR, asking them to add their notable team performance improvements and bugs fixes to the MRs you've created by providing them with the direct links
    • Copy the link from the above comment in this MR to @gitlab-com/backend-managers and @gitlab-org/frontend/frontend-managers and share it in Slack #development and Slack #eng-managers as well
    • In Slack #release-post, share the link to just the Bug Fixes MR and ask PMs to work with their EM to add high impact bugs to the MR
    • In Slack #release-post, share a link to just the Usability Improvements MR and ask PMs to work in partnership with their Product Designers to add line items that highlight significant usability improvements.

Recurring items starting on the 12th: @NicoleSchwartz

General Content Review As PMs finalize their release post items it can be helpful for the RPM to review and offer feedback. This reduces pressure on the 17th as items are merged and provides additional review from someone with a fresh perspective. You can start this as early as the 12th, but this should be an ongoing task leading up to content assembly on the 18th. Review each MR labeled Ready for content that follows handbook guidance. See What RPM should look for when reviewing content blocks.

To easily manage and track reviewed items do the following:

  • Bookmark a filtered MR list similar to this to track release post items you haven't reviewed. (note: add the correct milestone to that filter)
  • Add the rp manager reviewed label to any RP item you've reviewed.

Reminding and Alerting DRIs

It's important to keep DRIs up to date regularly with items they need to deliver for the release post. Especially given how async and distributed GitLab team members are early reminders are very helpful.

  • Alert DRIs (PMs, EMs and others as needed) at least one working day before each due date (post a comment to #release-post Slack channel)

General contributions @NicoleSchwartz

The release post is authored following a changelog-style system. Each item should be in an individual YAML file.

Contribution instructions

See Handbook: Contributing to the release post.

Content blocks

Due date: 2021-09-10 (10th)

Product Managers are responsible for raising MRs for their content blocks and ensuring they are reviewed by necessary contributors by the due date. Content blocks should also be added for any epics or notable community contributions that were delivered.

Product Managers are also responsible for making sure all required (Tech Writing) and recommended (PM Director and PMM) reviews get done for their content blocks. To help reviewers prioritize what to review, PMs should communicate which content blocks are most important for review by applying the proper labels to the release post item MR prior to assigning the MR to reviewers. (ex: Tech Writing, Direction, Deliverable, etc). PMs can also follow these guidelines to help decide which content blocks should get PM Director and PMM reviews.

To enable Engineering Managers to merge the content blocks as soon as an issue has closed, PMs should ensure all scheduled items have MRs created for them and have the Ready label applied when content contribution and reviews are completed.

Product Managers should only check their box below when all their content blocks (features, deprecations, etc.) are complete (documentation links, images, etc.). Please don't check the box if there are still things missing.

Reminder: be sure to reference your Direction items and Release features. All items which appear in our Upcoming Releases page should be included in the relevant release post. For more guidance about what to include in the release post please reference the Product Handbook.

Chief Product Officer and Team

Enablement

Dev

Sec

Ops

Fulfillment

Growth

Recurring content blocks

Due date: 2021-09-10 (10th)

The following sections are always present and managed by the PM or Eng lead owning the related area.

  • Add GitLab Runner improvements: @DarrenEastman
  • Add Omnibus improvements: @dorrino
  • Add Mattermost update to the Omnibus improvements section: @dorrino

Due date: 2021-09-15 (15th)

Final Merge

Due date: 2021-09-17 (17th)

Engineering managers listed in the MRs are responsible for merging as soon as the implementing issue(s) are officially part of the release. All release post items must be merged on or before the 17th of the month. Earlier merges are preferred whenever possible. If a feature is not ready and won't be included in the release, the EM should push the release post item to the next milestone.

To assist managers in determining whether a release contains a feature. The following procedure documented here is encouraged to be followed. In the coming releases, Product Management and Development will prioritize automating this process both so it's less error-prone and to make the notes more accurate to release cut.

Content assembly and initial review (@NicoleSchwartz)

Note: Final Content Assembly, and Structural Check steps all happen in sequence on the 18th starting ~8am PST (America/Los_Angeles). If the Release Post Manager and Technical Writer span many timezones it's recommended you coordinate ahead of the 18th to understand how this could impact working hours for each team member. If need be, the time of initiating the final content assembly and the subsequent coordinated tasks can be shifted, as long as Final content review with the CEO and CProdO begin no later ~12pm PST on the 19th, to allow enough time for feedback/updates.

**Due date: 2021-09-12** (12th) - Expand for Details
  • Per the instructions in the handbook request MVP nominations with a link to an issue for collaboration. Be sure to follow the instructions in the handbook page to maximize contributions to the MVP issue.
  • Remind PMs/EMs to contribute to the bugs, usability, and performance improvement MRs by commenting on the various Slack threads you initiated in #release-post, #development and #eng-managers by the 10th
**Due date: 2021-09-15** (15th) - Expand for Details
  • Select a cover image for the release post
  • Verify that the selected cover image has not been used before.
    • Tip: MacOS users, navigate to the source/images/ directory and use the search bar in the Finder to search for cover. Make sure the scope is set to only search "images". This won't reveal all previous images, but the last couple of years have had pretty consistent naming.
  • On the release-14-3 branch, add the cover image to source/images/14_3/14_3-cover-image.jpg. Tip: Be sure to use an _ between release numbers, not a -
  • On the release-14-3 branch, in sites/uncategorized/source/releases/posts/2021-09-22-gitlab-14-3-released.html.md, add details about the source image.
  • Choose an MVP for this release based on what's surfaced in the MVP issue
    • If no MVP nominations have been added to the MVP issue by the 15th, send reminders in Slack with the link to the MVP issue. An easy way to do this is to respond to your original Slack solicitation posts and resend to the whole channel.
    • Once one or more quality nominations have been received, choose one and notify via Slack #release-post of your choice. Use this chance to solicit any last-minute nominations and confirm that the contribution your pick was nominated for will make it into this release.
  • Before handing off the bugs, usability and performance improvements MRs to the TW lead for final review, remind PMs/EMs about the content due date by revisiting and commenting on the Slack threads you created by the 10th in #release-post #development and #eng-managers. Let them know it's "last call" and no further contributions to the MRs will be taken after the 15th.
  • In the threads of this MR, look for a GitLab Mattermost update. Please tag the Distribution PM as FYI and ask them to resolve the thread.
**Due date: 2021-09-17** (17th) - Expand for Details
  • Mention the Distribution PM in Slack #release-post, reminding them to add any relevant upgrade warning by doing an upgrade MR
  • If there are no deprecation MRs, ask in Slack #release-post if there are any deprecations to be included yet
  • Finalize your MVP selection and work with the nominator of the MVP to write the MVP section in data/release_posts/14_3/mvp.yml on the release-14-3 branch
  • On the release-14-3 branch, add the MVP's name and other profile info to data/mvps.yml
  • In Slack #release-post remind all PMs that it's the 17th so they need to either have their EMs merge their release post item MRs or bump the milestone if they know it won't make it
**Due date: 2021-09-18** (18th at 8 AM PT and NO earlier) - Expand for Details

  • Perform final content assembly by pulling all content block MRs merged to master into the release post branch by using the following commands locally (one command at a time):

    git checkout master
git pull
git checkout release-14-3
git pull
git merge master
bin/release-post-assemble
git push origin release-14-3

  • Do a visual check of the release-14-3 content block and image folders to make sure paths and names are correct

  • Make sure the release post branch View App generates as expected

  • Do a visual check of the blog post and ordering of content blocks for secondary items to confirm they are grouped by stage in descending alphabetical order.

  • Update the release post intro with 4 primary features to highlight. To do this

    • Mention the VP of Product Management @anoop in the appropriate section of this MR and ask him to add a Suggestion to update the intro, choosing no more than 4 features to highlight in order of importance. The top 2 features will used in the title of the post and the top 1 feature will be appear as the first feature in the release notes.
    • Be sure to provide the VP of Product Management with a clear time/date to do this based on when you want to do final reviews on the 19th.
    • Then post a follow-up to the VP Product Management in Slack #release-post with a link to the Comment you've created in this MR letting him know he needs to take action by the date/time you designated or you'll choose the features to highlight and move forward.
    • Link the release post items mentioned in the intro to the item blocks within the release post. For example, for a feature named "Define test cases in GitLab", the link from the introduction should point to #define-test-cases-in-gitlab
    • Count the feature blocks to get the total number of improvements and add it to the intro. This includes the top feature, primary features, secondary features, and performance improvements. Do not count bugs, upgrades, etc.
    • Mark the first primary item, based on what the VP of Product Management decided, to appear on the page as top while the rest can remain primary or secondary.

  • On the release-14-3 branch, update the release blurb for the homepage in the file: /sites/uncategorized/source/includes/home/ten-oh-announcement.html.haml changing the following lines:

    • Update the %h1 X.X line to the latest verion.
    • Update the text under the release description with a copy/paste the blog title. For example, GitLab X.X released with Feature A and Feature B.
    • Update the link_to line with the URL of the blog. For example, /releases/2021/06/22/gitlab-14-0-released/.
    • Update the "name":"GitLab X.X" line to the latest version.
    • Update the releaseNotes to the URL of the blog. For example, "releaseNotes":"https://about.gitlab.com/releases/2021/06/22/gitlab-14-0-released/".
    • Update the "softwareVersion":"X.X" line to the latest version.

  • Ensure that the social media sharing text for the click to tweet button on the bottom of the release post is available in the introduction.

  • Notify the PM team in #release-post Slack channel that final content assembly has happened and all work must now shift from master onto the release post branch via coordination with the release post manager.

    • Include a link to the View App, asking them to make sure all their content is showing up as expected with correct image/video links, etc. and that as confirmation of their final review, to check off their content and recurring blocks in the release post MR.
    • Be sure to link them to the content and recurring blocks section in the MR as part of the post

Note: If the release post assembly script fails, look at the bottom of this section of the release post handbook page for further instruction

**Due date: 2021-09-18** (18th) - Expand for Details
  • Label this MR: ~"blog post" release review-in-progress
  • Check if there are no broken links in the View App (use a dead link checker, e.g., Check my Links)
    • Links to confidential issues may be missed. It is helpful to check for broken links as an unauthenticated GitLab user (either logged out, in another browser, or in Incognito mode).
    • If there are links to external blogs that are still broken in the review app, check with PMs and others as needed to make sure the referenced blogs go live before the 22nd.
  • Check all comments in the MR thread (make sure no contribution was left behind).
  • Make sure all discussions in the thread are resolved.
  • Assign the MR to the next reviewer (Technical Writer for the Structural Check).
**Due date: 2021-09-20** (20th) - Expand for Details
  • Check if the number of features you added in the introductory paragraph has changed. To get the number, you'll do a hand count of just features (top, primary, secondary) and performance improvements (do not include bugs, upgrades, etc.) in /data/release_posts/14_3 on the current release-14-3 branch.
  • Post in the #release-post channel: Hello PMs! The following features are top/primary! (Provide link to View App and tag the PMs of the top/primary features listed in the release post). Please let us know if any of your merged primary release post items shifted out of the release after the 18th and will not make it into the final release packages by the 22nd.
    • Tell them they can check this query (modify by the milestone) and check with their EMs to verify that it did make it.
    • It is the Release Post Manager's responsibility to make sure any top/primary items mentioned in the introduction are accurate prior to the 22nd since release post items can sometimes move in/out of the packaged release after the 18th, and this could affect the themes, headline, etc.
    • If you learn that any top/primary items have moved in/out of the packaged release after the 18th, then communicate this directly to stop or start associated actions, with the DRIs for: Technical Marketing (the TMM team) who produce demo videos per release, Social Marketing who produce feature campaigns per release, Corporate Communications who lead media outreach and may have produced a press release, and any related efforts you're aware of e.g. for related blog posts.

Other reviews

Ideally, complete the reviews by the 19th of the month, so that the 2 days before the release can be left for fixes and small improvements.

Structural check (@kpaizee)

**Due date: 2021-09-18** (18th) - Expand for Details

The structural check is performed by the technical writing lead: @kpaizee

For suggestions that you are confident don't need to be reviewed, change them locally and push a commit directly to save the PMs from unneeded reviews. For example:

  • clear typos, like this is a typpo
  • minor front matter issues, like single quotes instead of double quotes, or vice versa
  • extra whitespace

For any changes to the content itself, make suggestions directly on the release post diff, and be sure to ping the reporter for that block in the suggestion comment, so that they can find it easily.

The TW lead is also responsible for ensuring that the next version of the documentation site is published to match the current release. This process should start around the same time as the release post structural check, and finish on or near the 22nd.

In the www-gitlab-com repository:

  • Check frontmatter entries and syntax.
  • Check that the item's name contains backticks when referring to code. (Previously we had to use single quotes, but backticks work now.)
  • Check all images (png, jpg, and gifs) are smaller than 150 KB each.
  • Remove any .gitkeep files accidentally included.
  • Add or check cover_img: license block (at the end of the post). Should include image_url:, license:, license_url:.
  • Search for available_in: [free, premium, ultimate] and change to available_in: [core, premium, ultimate].

In the review app:

  • Check that images match the context in which they are used, and are clear.
  • Check for duplicate entries.
  • Search for the text gitlab-ci.yml and ensure there is a period before the filename, for example, .gitlab-ci.yml.
  • Check that features introduced in this release do not mistakenly reference previous releases (this often happens after features slip to a future release after an RPI is already written). If, for example, the current release is 13.8, and an item reads: "In GitLab 13.7 we introduced XXX...", this means the feature most likely slipped to 13.8. In that case, correct the text to "In GitLab 13.8 we introduced XXX...". A search for two or three previous release numbers ("13.7", "13.6", and "13.5" in our example) in the review app should be enough to spot this.
  • Check all dates mentioned in entries, ensuring they refer to the correct year.
  • Check the anchor links in the intro. All links in the release post markdown file should point to something in the release post Yaml file.
  • Run a dead link checker, e.g., Check my Links and ping reporters directly on Slack asking them to fix broken links.
    • Links to confidential issues may be missed. It is helpful to check for broken links as an unauthenticated GitLab user (either logged out, in another browser, or in Incognito mode).
  • Run a spelling check against the Release Post's View app. For example, using Webpage Spell-Check for Google Chrome.

In general:

  • Report any problems from structural check in the #release-post channel by pinging the reporters directly for each problem. Do NOT ping @all or @channel nor leave a general message to which no one will pay attention. If possible, ensure open discussions in the merge request track any issues.
  • Post a comment in the #whats-happening-at-gitlab channel linking to the View App + merge request reminding the team to take a look at the release post and to report problems in #release-post. CC the release post manager. Template to use (replace links): 
    Hey all! This month's release post is almost ready! Take a look at it and either
report any problems in #release-post, or leave a comment to the release post MR.
MR: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/1234
View app: https://release-14-3.about.gitlab-review.app/releases/2021/09/22/gitlab-14-3-released/index.html
  • Remove the label review-structure.
  • Assign the MR to the next reviewer (release post manager)
  • Notify release post manager that you're done with the structural check needed for final content review, by pinging them in the Slack 14-3 release post prep channel.
  • Within 1 week, update the release post templates and release post handbook with anything that comes up during the process.

Final content review (@NicoleSchwartz)

**Due date: 2021-09-19** (18th - 19th) - Expand for Details
  • Check to be sure there are no broken links in the View app (use a dead link checker, e.g., Check my Links
  • Mention @sytse, @sfwgitlab, and @adawar in #release-post on Slack when the post has been generated for their review per these communication guidelines
  • Capture any feedback from Slack into a single comment on the Release Post MR with action items assigned to the DRIs to address. More info here
  • Request that the VP of Product Management @adawar identify the 3-7 items for **What's New ** by posting in Slack #release-post and linking him to Creating an MR for What's New entries in the handbook. cc What's new DRIs Product operations '@fseifoddiniand Growth@mkarampalas` in the Slack post.
    • This task should not happen prior to the 19th, in order to give sufficient time to be confident the features being released are fully confirmed. At the discretion of the release post manager, this task may be done on the 20th but no later.

Incorporating Feedback

Due date: 2021-09-20** (by the 20th) Expand for Details
  • Make sure all feedback from CEO and Product team reviews have been addressed by working with DRIs of those areas as needed
  • If you receive feedback about the ordering Primary Items, you might need to adjust the order.
  • If applicable re-order Secondary items by adjusting the titles in the content blocks. More information to consider about altering secondary items here | technical instructions
  • Make sure there are no open feedback items in this MR or in Slack #release-post channel
  • On 20th, ping Product Operations (@fseifoddini) for final check in Slack #release-post
  • After Product Operations review, remove the label review-in-progress

Preparing to merge to master (@NicoleSchwartz)

On the 21st

Expand for Details
  • Mention @community-team on Slack #swag to ask them to send the swag pack to the MVP
  • Check if all the anchor links in the intro are working
  • Confirm there are no broken links in the View app (use a dead link checker, e.g., Check my Links)
  • Check the total features count statement in the introductory paragraph to make sure the number stated is accurate, and if not, update it. To get the number, you'll do a hand count of the top feature, primary features, secondary features, and performance improvements (do not count bugs, upgrades, etc.) in /data/release_posts/14_3 on the current release-14-3 branch.
  • Work with your Technical Advisor to merge master into your release post branch before the 22nd. This prevents having to resolve conflicts when merging the release post branch into master on the 22nd. This issue shows an example of how this process can be handled: #10886 (closed).
  • Check to make sure all unresolved threads on this MR are resolved and there are no merge conflicts. If you need help resolving merge conflicts or other technical problems, ask for help from the Technical Advisor in #dev-escalation channel in Slack then cross-post to #release-post channel to make others aware.
  • Reach out to the [release managers (https://about.gitlab.com/community/release-managers/) the day before the release to let them know you are running the release and ask them to keep you in the loop on the release.

On the 22nd (@NicoleSchwartz)

At 12:30 UTC

Expand for Details
  • Read the important notes below
  • Say hello in #releases slack channel to let the release managers you're online and await their signal in #release-post to start the merge process of the release post.
    • Release Managers will alert you in #release-post if there are any issues with the release. You can follow along on the release issue to see the packaging progress on the 22nd | issue list example issue. The #releases slack channel is also a good place to track any updates or announcements.
    • If everything is okay, the packages should be published at 13:30 UTC, and available publicly around 14:10 UTC.
  • Check to make sure there aren't any alerts on Slack #release-post and #whats-happening-at-gitlab channels
  • Check to make sure there aren't any alerts on this MR or merge conflicts

Merging to master (@NicoleSchwartz)

At 13:50 UTC

Expand for Details Once the release manager confirmed that the packages are publicly available by pinging you in Slack:
  • Announce to the team in #release-post that you are starting the final merge process and will reach out for help if the MR fails and that you will lead collaboration with the appropriate team members to resolve problems
  • Add the MR to the merge train at 14:10-14:20 UTC.
  • Wait for the pipeline. This can take anywhere from 20-45 minutes to complete.
  • Check the live URL on social media (after MR is merged) with Twitter Card Validator and Facebook Debugger. You may get a warning from Facebook that says "Missing Properties - The following required properties are missing: fb:app_id" - this can be ignored.
  • Check for broken links again once the post is live.
  • Handoff social posts to the social team and confirm that it's ready to publish: Mention @social in the #release-post Slack channel; be sure to include the live URL link and social media copy (you can copy/paste the final copy from the View app).
    • A member of the social team will schedule the posts at the next available best time on the same day. The social team will mark the Slack message with a ⏳ once scheduled and add scheduled times to the post thread for team awareness. Further details are listed below in the Important Notes Section.
  • Share the links to the post on the #release-posts and #whats-happening-at-gitlab channels on Slack.

What to do if your pipeline fails or you have other technical problems

For assistance related to failed pipelines or eleventh-hour issues merging the release post, reach out to release post technical advisors for assistance in the #dev-escalation Slack channel. Cross-post the thread from #dev-escalation in #release-post so all Product Managers and release post stakeholders are aware of status and delays.

Important notes

  • The post is to be live on the 22nd at 15:00 UTC. It should be merged and as soon as GitLab.com is up and running on the new release version (or the latest RC that has the same features as the release), and once all packages are publicly available. Not before. Ideally, merge it around 14:20 UTC as the pipeline takes about 40 min to run.
  • The usual release time is 15:00 UTC but it varies according to the deployment. If something comes up and delays the release, the release post will be delayed with the release.
  • Coordinate the timing with the release managers. Ask them to keep you in the loop. Ideally, the packages should be published around 13:30-13:40, so they will be publicly available around 14:10 and you'll be able to merge the post at 14:20ish.
  • Once the release post is live, wait a few minutes to see if no one spots an error (usually posted in #whats-happening-at-gitlab or #company-fyi), then follow the handoff to social team checklist item above.
  • The tweet to share on Slack will not be live, it will be scheduled during a peak awareness time on the 22nd. Once the tweet is live, the social team will share the tweet link in the #release-post and in the #whats-happening-at-gitlab Slack channels.
  • Keep an eye on Slack and in the blog post comments for a few hours to make sure no one found anything that needs fixing.
Edited by Farnoosh Seifoddini

Merge request reports