Overview

Note: There are several tasks in this checklist that can be done any time before the listed due date. If a task says "no earlier than", it is important to follow that guideline.

Opening tasks

Due date: Wednesday, 2026-03-04, 15 days before the release day

Calendar

1. Schedule a coffee chat with the previous RPM to get advice and updated information.
2. Schedule a 25-minute retrospective meeting with the release post team as soon as possible after the release day.
3. Schedule two weekly 15-minute standups using this agenda template.
   • Avoid scheduling them on Mondays when possible due to time zones and holidays.
   • Invite the TW Lead, Tech Advisor (required), and PMM Lead
   • If time zones pose a challenge, use #release-post-prep for virtual standups at a consistent time/day.
4. Review the major due dates in the standup agenda.
   • If any fall on weekends, holidays, or Family and Friends day, inform your release post team in #release-post-prep to make necessary arrangements.
5. Confirm that the release post bot initialized the release post with initial commits by the 3rd of the month. Ex. You may expect to see 3 commits for Init release post for 16.x,Updated removals content, and Updated deprecations content. If no initial commits are visible, the automation may have failed. In this case, reach out to your technical advisor for support.

#release-post-prep

1. Join the #release-post-prep channel in Slack.

   1. Invite uchandran, tbd, thelle, tbd. There is no need to invite the social team to the channel.

2. Update the #release-post-prep Slack bookmarks in the #release-post-prep channel:

   MR: RP_MR_LINK
   Preview page: https://about.gitlab.com/releases/gitlab-com/
   Review App: https://release-18-10.about.gitlab-review.app/releases/2026-03-19/gitlab-18-10-released/
   Retro issue: RETRO_ISSUE_LINK
   Notable Contributor nominations: NOTABLE_CONTRIBUTOR_ISSUE_LINK

3. Paste the following in #release-post-prep:

   Hi team! This channel is to discuss production-specific topics that don't concern the broader product team. By keeping our conversations in this channel, we can help keep #release-post clean.
   
   :brain: TW Lead and Tech Advisor, please take a minute to look over your roles in the Handbook and consider a coffee chat with the previous team member in your role.
   
   - [TW Lead](https://handbook.gitlab.com/handbook/marketing/blog/release-posts/#tw-lead)
   - [Tech Advisor](https://handbook.gitlab.com/handbook/marketing/blog/release-posts/#technical-advisors)
   
   Also, uchandran, just a gentle reminder not to merge in changes from master to the release post branch. I will take care of all changes to the release post branch; even if there is a merge conflict or things are falling behind.

#release-post

1. Update the #release-post Slack bookmarks in the #release-post channel:

   MR: RP_MR_LINK
   Preview page: https://about.gitlab.com/releases/gitlab-com/
   Review App: https://release-18-10.about.gitlab-review.app/releases/2026-03-19/gitlab-18-10-released/
   Retro issue: RETRO_ISSUE_LINK
   Notable Contributor nomination: NOTABLE_CONTRIBUTOR_ISSUE_LINK

2. Paste the following in #release-post:

   Hi team! I'll be your release post manager for 18.10! I'm joined by uchandran as our TW Lead and tbd will be our Tech Advisor for this release.

Confirm Slackbot reminder

Due date: Monday of the week the milestone ends, 2026-03-09

1. Paste the following in #release-post (Note: this can be scheduled in advance):

   :hourglass_flowing_sand: **Release post item MRs must be merged to `master` by the 2026-03-16 at 4p UTC / 11a ET / 8a PT.**
   
   The script that will merge your MRs from `master` and into the upcoming release post MR will run on 2026-03-16 at 4p UTC / 11a ET / 8a PT.
   
   Please be sure your release post items have been merged into `master` and ready to go.

2. (optional) We have created a script, which allows you to automatically comment on all open release post item MRs for the current milestone, and ping all involved people with the deadline. To run the script, follow the usage instructions of the gilab-messaging-bot. It will require to create a personal access token and update the message - but will provide you the ability to comment all required people - which might decrease the late additions.

Timing of Final Content Assembly and Structural Check

On the Monday of release week, Final Content Assembly and Structural Check steps will start around 8 AM PST.

Coordination between the RPM and TW Lead is necessary if they are in different time zones to minimize disruption. Starting time may be adjusted, but Final Content Review with product leaders must start by 12 PM PST on the Tuesday of release week to allow time for feedback and changes.

1. On the Monday of the release week, remind prople in #release-post. (Note: this is recommended to be scheduled in advance so people in EMEA-APAC timezones can see it early in their working hours)

   :exclamation:  Final call - Release post item MRs MUST be merged to `master` today by 4p UTC / 12a ET / 9a PT. :hourglass_flowing_sand: :exclamation:
   
   Please check if your feature made it to the [latest announced stable release version](https://gitlab.slack.com/archives/C0XM5UU6B/p1718629508182249?thread_ts=1718617038.879679&cid=C0XM5UU6B). You can check if an MR made the cut by using the following ChatOps command: `/chatops run release check [MR_URL] 18.10` in the `#releases` Slack channel.
   If your feature didn't make the release, please adjust the milestone accordingly.
   
   Any late Release Post additions will need approval and follow the [late additions process](https://handbook.gitlab.com/handbook/marketing/blog/release-posts/#requesting-late-addition-before-release-date).
   
   If you have any questions please reach out in Slack `#release-post` or reach out to the [current Release Post Manager](https://handbook.gitlab.com/handbook/marketing/blog/release-posts/managers/)
   
   cc @product-team

2. You can check if there is any open Release Post Item MRs. Since the milestone is likely closed at this point, you'll have to manually adjust the filter for the right release.

Due date: the Friday the milestone ends, 2026-03-13

Engineering managers listed in the MRs are responsible for merging content blocks (release post item MRs) as soon as the implementing issue(s) are officially part of the release. All release post items must be merged on or before the Friday the milestone ends. 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.

Due date: the Friday the milestone ends, 2026-03-13

1. In the #release-post-prep channel, remind the team that from the Monday of release week and the release day, release post team members are asked to maintain a one-hour response time in Slack during their working hours. This is to ensure the smooth progression of time-sensitive tasks during this window.

   :waves: Hi Team - This is a reminder that we have a 1 hour SLA from the Monday of release week and the release day.  Here is a list of each of our timezones and working hours in UTC.  Hopefully this will make coordination during the 1 hour SLA windows for a little easier.

Due date: Monday of release week, (2026-03-16), at 4 pm UTC (11 am ET / 8 am PT) and NO earlier

1. Rebase release-18-10 branch with master so all unreleased items are on the release branch. This will allow the content assembly bot to move items in unreleased folder to 18_10 folder.

2. Once content assembly is confirmed complete, paste the following in #release-post:

   Content assembly is complete

   Any unmerged release post items that need to be in the upcoming release post or any merged items that need to be removed from the release post can be modified by following these steps.

Once the Release Post Content Assembly bot runs after the release post branch has been rebased, check the release-18-10 branch:

1. Verify the presence of .yml files in the 18_10 data directory: data/release_posts/18_10/.
2. Verify the absence of .yml files in the unreleased data directory: data/release_posts/unreleased/.
   • In case there are files left, discuss with the Tech Advisor whether to move them manually or to delete them.
3. Verify the presence of image files in the 18_10 image directory: source/images/18_10/.
4. Verify the absence of image files in the unreleased image directory: source/images/unreleased/.
   • In case there are files left, discuss with the Tech Advisor whether to move them manually or to delete them.
5. Verify the presence of a cover image in source/images/18_10.
   • Download the desktop cover image associated with your release from Google Drive and upload it to the proper directory in source/images/18_10. If you can't find an image in the Drive folders, create a request similar to this one to have them created.
   • Update image_title and twitter_image lines in sites/uncategorized/source/releases/posts/2026-03-19-gitlab-18-10-released.html.md.
   • Add a line rebrand_cover_img: true at the end of the block (example MR).
   • Remove the cover image license block (cover_img), because it's not needed for GitLab-generated images.
6. Do a check of the blog post and ordering of content blocks for secondary items to confirm they are grouped by stage (the icons next to the content block indicate stage) are sorted by their order in this list and then by the title. This can be done using the view app.
   • Be sure to wait until after the content bot runs. Otherwise, content may be missing or incomplete.
   • If any of the steps above cannot be verified, content assembly may have failed. Mention tbd in a comment on this MR and in #release-post-prep and proceed with the steps below. Optionally, you may choose to move the files manually by following the steps outlined here.
   • If the length of one column is much longer than the other, you can force a block of content from the left to the right or vice versa by adding a force_left: true or force_right: true to an entry's yml file. (Example)
   • If there are beta or experimental features in this release, confirm that those beta features render properly.
7. Update the release post intro in the sites/uncategorized/source/releases/posts/2026-03-19-gitlab-18-10-released.html.md with up to 4 primary features to highlight. To do this:
   1. Make sure to remove the backticks around the features.
   2. Make sure to update the feature placeholder text for title: and description:.
   3. Verify and adjust the author: field. It should contain the full name of the release post manager.
   4. 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. Do not use the full link from the Review App as it will change when published.
   5. Count the feature blocks to get the total number of improvements and add it to the intro, replace the XX in from the XX improvements and remove the backticks in sites/uncategorized/source/releases/posts/2026-03-19-gitlab-18-10-released.html.md. This count includes the top feature, primary features, secondary features, usability improvements, and performance improvements. Do not count bugs, upgrades, etc. You should use an approximate count (i.e. 40+ instead of 43) because the number can shift after the release post goes live.
   6. Replace the XX in We thank our community for the XX contributions with the count of merged milestones found in the chart for merged MRs per milestone based on date. Remove the backticks as well.
   7. Pick a primary feature entry to be the top feature and change the type from primary to top.
      1. If you are unsure what to pick, you can solicit feedback from @product-team in #release-post.
   8. Rename the featured top and primary release post items .yml files to start with numbers starting at 0 for the top item in the order as featured. This will enforce ordering in the rendered version, and also make working on these MRs easier, since they are easier to navigate. This is also required to run the What's New Generator script.
8. In the #contributor-success channel:
   • Remind the Contributor Success team that the Notable Contributor MR is due on the Tuesday of release week.
   • Ask the Contributor Success team to verify the total number of contributions in the community thank you is correct.

Hi Team - I'm the release post manager for release 18.10. This is a reminder that the Notable Contributor for this release is due on the Tuesday of release week.

1. Ensure that the social sharing text is available and correct on the release post. This text comes from the title: element in sites/uncategorized/source/releases/posts/2026-03-19-gitlab-18-10-released.html.md and should appear below the post introduction inside the social sharing block. View the release post in the Review App and look for Click to tweet! to find the social sharing text.

TW review cannot proceed if content assembly is incomplete. Only perform these steps if the content assembly verification you performed above has passed.

Due date: Monday of release week, 2026-03-16

1. Make sure there are no broken links in the Review App (View App) page. Use a broken links checker like DNS checker or Dead link checker. This should work without creating an account.

   The following links are expected to be broken at this time:

   • GitLab Runner CHANGELOG.md. This is resolved by the Runner team at the time of publication.

   • Links associated with Stage icons or SM/SaaS tiers (Free/Premium/Ultimate). They will work upon merging to master.

     If for some reason (although you shouldn't need to), you need to fix broken icon links for the different stages, you can do so by adding stage_url: '/stages-devops-lifecycle/' underneath stage as in this example.

   1. 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).
   2. 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 release day.
   3. Make sure the video links work and that the video is set to public, so that the content can be seen by an audience external to GitLab.

2. Check all comments in the MR thread (make sure no contribution was left behind).

3. Make sure all discussions in the thread are resolved.

4. Confirm the list of breaking change deprecations and removals in the release post reflects the deprecations and removals in docs. Search the deprecations page to make sure there aren't any removals this milestone that got missed. Not all removals happen on major x.0 releases. Note: non-breaking deprecation announcements are not displayed when filtering the page by removal version.

5. On the docs pages, all H2 titles that apply to the release should be listed as bullets at the bottom of the release post. In case there are deprecations missing from the release post preview:

   1. Copy the missing headlines from the deprecations overview into /data/release_posts/deprecations-index.yml/ and commit the changes. Make sure the bullet points are listed in alphabetical order.
   2. Check whether the additional bullet points are present in the Review App once it has been recompiled

6. Check if any removals in this release post milestone are indicated as "Breaking Changes" in docs.

7. If the pipeline is failing, confirm all release post content blocks have the right formatting. Common issues include extra spaces, missing quotes, or missing --- at the beginning and end. If you are unable to locate these items, give the TW lead a heads up and proceed with TW Lead structural check.

8. Assign the MR to the next reviewer (TW lead) and ping them to complete the structural check.

9. Ask the Tech Advisor in Slack #release-post-prep channel to prep handoff of any release post issues to the next Tech Advisor by referencing TA handoff.

Due date: Monday of release week, 2026-03-16

The structural check is performed by the technical writing lead: uchandran

Outside of the structural check, the TW lead should also be available for MR reviews for late submissions on the Tuesday and Wednesday before the release day. Remember that members of the release post team have a one-hour response time in Slack during their working hours on these dates.

When starting the structural check:

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:

• Obvious 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 ping the author in the suggestion comment, so they can find it easily.

❗ Report any problems from the structural check in the #release-post-prep channel by pinging the reporters directly for each problem. Do NOT ping @all or @channel, and do NOT leave a general message that no one will pay attention to. If possible, ensure open discussion threads in this merge request track any issues.

In the release post MR diff:

1. Remove any .gitkeep files accidentally included.
2. Check the cover_img: license block in /releases/posts/2026-03-19-gitlab-18-10-released.html.md. If the image was generated by Marketing (which it often is), remove the cover_image: license block, if present. If the content assembly checklist point Verify the presence of a cover image in... is selected, this should mean the cover_img: license block is not in the MR diff.
3. Search for available_in: [free, premium, ultimate] and change to available_in: [core, premium, ultimate].
4. Confirm that the field names for issue, epic, merge request, and webpage URLs are correct. For example, mr_url for merge request URLs, issue_url for issue URLs.

In the Review App:

1. Check for duplicate entries.
2. Search for the text gitlab-ci.yml and ensure there is a period before the filename, for example, .gitlab-ci.yml.
3. Check that features introduced in this release do not mistakenly reference previous releases.
4. Check all dates to ensure they refer to the correct year.
5. 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.
6. Run a spell check against the release post's Review App (View App) page. For example, you can run a spell check on a page by making the content editable by using the developer console in your browser.
7. Confirm the list of deprecations and removals in the release post matches the list in the docs. The release post only lists breaking changes, so if there is a difference between the two lists, check this first. In the docs, all H3 titles that apply to the release should be listed. Ping the RPM if there is a mismatch. This list could be empty if there were no announced breaking changes for this release.

In general:

1. Ping the release post manager in Slack #release-post-prep to let them know your review is over and they can start final content review.
2. Approve the release post merge request to communicate you have completed your tasks.

After the Monday of release week

1. Within 1 week of the structural check, update the release post templates and release post handbook with anything that comes up during the process.
2. Set a reminder for yourself on the Friday the milestone ends of the following month to prepare for the versioned documentation release.

By Wednesday of release week

The RPM creates the What's New MR starting on the Tuesday of release week and should request a review from the TW Lead when the MR is ready. The TW Lead must review the MR by 11:59 PDT on the Wednesday. If the RPM does not request a review by Wednesday morning PDT, the TW Lead should ping the RPM on Slack about the status of the MR.

You can find TW review instructions for What's New MRs in the Create What's New MR checklist in this template.

Due date: Tuesday of release week, 2026-03-17

Note: The final review should happen after the TW Lead structural check is complete.

Verify content and post for review

1. Check to be sure there are no broken links in the View App (use a dead link checker like Check my Links. Note that the link to the GitLab Runner CHANGELOG.md will be broken at this time. This is expected and will be resolved by the Runner team at the time of publication.

2. Check the Review App URL on social media with Meta Tags. Note that you don't need a social media account to do this. You probably won't be able to see the cover image of the release post displayed along with social sharing copy. This should get fixed after the release post is published. Check if social sharing copy is present and accurate.

   1. The title:, description: and twitter_image: values in the release post markdown file are used for generating social media metadata.
   2. You may get a warning from Facebook that says Missing Properties - The following required properties are missing: fb:app_id - this can be ignored.

3. Check deprecations in Docs to see if there were any breaking change deprecations listed with a planned removal date for the current milestone. If so, make sure that you see those breaking change deprecations listed in the removals section of your release post page (View App). If there's any missing, alert the PM DRI to get it resolved.

4. Mention @product-leaders in the #release-post channel when the post has been generated for their review per these communication guidelines.

   @product-leaders - The 18.10 Release Post has been generated and can be reviewed at `https://release-18-10.about.gitlab-review.app/releases/2026/03/19/gitlab-18-10-released/`.  The 18.10 release post MR is `RP_MR_LINK`
   Please share your feedback by 6 pm UTC (1 pm ET / 11 am MT/ 10 am PT) on DAY. Thank you for your review!
   Note: Currently there are no known issues/adjustments to the content.
   For review: oazaria, uchandran, thelle, @social

5. Capture any feedback from Slack into a single comment on the Release Post MR with action items assigned to the DRIs to address. Check the content review guidelines for more details.

Incorporating Feedback

1. Make sure all feedback from Product team reviews have been addressed by working with the DRIs of those areas as needed.
2. If you receive feedback about the ordering of the primary items, you might need to adjust the order.
3. If needed, re-order secondary items by adjusting the titles in the content blocks. More information to consider about altering secondary items in the content review guidelines and feature order technical instructions.
4. Make sure there are no open feedback items in this MR or in the #release-post channel.

Branch maintenance

1. Check if the number of features you added in the introductory paragraph has changed. To get the number, do a hand count of just the features (top, primary, secondary) in /data/release_posts/18_10, and also count the number of items in the performance improvements and the usability improvements files in the current release-18-10 branch. Do not include bugs, upgrades, etc. You can use an approximate count (i.e. 40+ instead of 43). Remove the backticks around the number if you have not already.
2. Check if the number of merged community contributions you added in the introductory paragraph has changed. Remove the backticks around the number if you have not already.
3. Verify that the Notable Contributor content has been updated and rendering correctly. The fullname and gitlab fields should not be set to false in the data/release_posts/18_10/mvp.yml file, instead they should be populated with the nominated contributor's details.

Announcements

1. Alert the product team of the top/primary items in Slack.

   1. PMs can use this query (update it with the current milestone) and check with their EMs to verify the features did make it into the release.
   2. Post in the #release-post channel:

   _Hello PMs! The following features are top/primary!_
   
   Review App: https://release-18-10.about.gitlab-review.app/releases/2026/03/19/gitlab-18-10-released/index.html
   
   (Tag the PMs for 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 Monday of release week and will not make it into the final release packages by the release day._

2. Top/Primary items can move.

   1. It is the RPM's responsibility to make sure any top/primary items mentioned in the introduction are accurate prior to the release day, because release post items can sometimes move in/out of the packaged release after the Monday of release week, and this could affect the themes, headline, etc.
   2. If you learn that any top/primary items have moved in/out of the packaged release after the Monday of release week, communicate this directly to stop or start associated actions, with the DRIs for:
      1. Technical Marketing (the TMM team), who produce demo videos per release.
      2. Social Marketing, who produce feature campaigns per release.
      3. Corporate Communications, who lead media outreach and may have produced a press release.
      4. Any other related efforts you're aware of, for example related blog posts.

3. Post a comment in the #whats-happening-at-gitlab channel.

   Hey all!
   This month's release post is almost ready!
   Take a look at the preview and either report any problems in `#release-post`, or leave a comment to the release post MR.
   MR: RP_MR_LINK
   Review App (this link is temporary and should only be shared internally):
   https://release-18-10.about.gitlab-review.app/releases/2026/03/19/gitlab-18-10-released/index.html
   cc lohrc

Create the What's New MR

To complete these tasks, you will need to

1. Identify the 3-7 items for What's New and create the MR using one of the following:
   1. Follow the guidance in Creating an MR for What's New entries, or
   2. Run the generate-whats-new job. This script will generate a what's new .yml file using the top and primary items and a MR info .md file.
      1. Download the artifact files, or copy the text from the job log.
      2. Double check and edit the contents as necessary. Many descriptions are quite long and should be shortened.
      3. Optionally, add or remove release post items.
      4. Create a MR in whats_new folder by adding the YAML file, or by copy and pasting the content from the generated file. You can see this either in the job log or by downloading the artifact of the previous job.
2. All of the .yml files of these release post items should start with an number in the correct order from 0-6 as they should be featured. If you haven't done so before you can rename them now.
3. If missing, add the label typemaintenance to stop the GitLab bot from complaining about a missing type label.
4. Post the following message in #backend_maintainers on Slack: I am the release post manager for 18.10 and will need help merging in the "What's new" notification following the publication of the release post. This will be a time-sensitive MR on the release day (15:00-19:00 UTC). Could I please request a volunteer or two to be ready and available to help merge the MR when I have it ready to go? Thanks! cc: @a_akgun
5. Create and finalize the MR draft by 11:59 PDT on Wednesday, the day before the release day.
6. Tag in any maintainers who respond to the above message in #backend_maintainers as Reviewers, to review and approve.
7. If you do not have merge rights on gitlab-org/gitlab, mention to the maintainers you've tagged above that you will need them to merge this MR after the release post is live on the release day. (There is a task on the release day reminding you to merge or request to merge.).

Technical Writing review of the What's New MR

1. Review the "What's New" MR and provide feedback on:
   1. Clarity and accuracy of the feature descriptions
   2. Proper use of GitLab style and terminology
   3. Proper use of links and references
   4. Proper formatting and structure
2. Approve the "What's New" MR if all feedback has been addressed

When going through the release checklist, keep in mind:

• The name: value should be encased in double quotes ("").
• available_in: values should be [Free, Premium, Ultimate], not [core, premium, ultimate].
• documentation_link: and image_link: values should not be encased in single quotes ('').

Due date: 2026-03-18

1. Check if all the anchor links in the intro are working.
2. Confirm there are no broken links in the Review App (View App) with a dead link checker like Check my Links). Note that the link to the GitLab Runner CHANGELOG.md will be broken at this time. This is expected and will be resolved by the Runner team at the time of publication.
3. Check the total feature count statement in the introductory paragraph to make sure the number stated is accurate, and if not, update it. To get the number, 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/ on the current release-18-10 branch.
4. If needed, use the /rebase quick action to rebase master on to the release-18-10 branch. If you receive an error that the rebase cannot be scheduled, consult with the Tech Advisor.
5. 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 the #dev-escalationchannel in Slack then cross-post to the #release-post channel to make others aware.
6. In the #releases channel, post the following: " I'm the release post manager for 18.10. I'll be awaiting your cue that packages have been released to push the release post live. Please let me know if there are any changes to the typical timeline."

Due date: Release day, 2026-03-19

At 12:30 UTC

1. Read the important notes below.
2. Say hello in the #releases channel to let the release managers know you're online and awaiting their signal in #release-post to start the release post's merge process.
   1. 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 release day. Check the issue list to find the issue for the current monthly release. The #releases channel is also a good place to track any updates or announcements.
   2. If everything is okay, the packages should be published around 13:30 UTC, and available publicly around 14:10 UTC.
3. Check to make sure there aren't any alerts on in the #release-post and #whats-happening-at-gitlab channels.
4. Check to make sure there aren't any alerts on this MR or merge conflicts.

When packages are published (usually around 14:00 UTC)

After the release manager confirms that the packages are publicly available by pinging you in Slack:

1. Announce to the team in the #release-post channel that you are starting the final merge process, you will reach out for help if the MR fails, and that you will lead collaboration with the appropriate team members to resolve any problems.

   :waves: Hi Team - I am starting the final merge process for the 18-10 Release Post ([MR](RP_MR_LINK))!  I will reach out for help if the MR fails and collaborate with appropriate team members to resolve any problems.

   1. Depending on the complexity of the failure it is recommended that you first try to resolve the issue yourself and then reach out to the #dev-escalation channel per What to do if your pipeline fails or you have other technical problems.

2. Merge release post MR:

   1. Remove "Draft:" from the title of the MR
   2. Uncheck Delete source branch
   3. Check Squash commits
   4. Add the MR to - the merge train.

3. Wait for the pipeline. This can take anywhere from 20-45 minutes to complete.

4. Check the live URL on social media (after the MR is merged) with Meta Tags. Make sure that in both cases, you can see the cover image of the release post displayed along with social sharing copy.

   1. If the cover image is not displaying or you see other error messages, resolve these issues by consulting with the Tech Advisor or Social team as needed.
   2. You may get a warning from Facebook that says Missing Properties - The following required properties are missing: fb:app_id - this can be ignored.

5. Check for broken links again after the post is live.

6. Hand off for social and blog teams: Mention @social and @Sgittlen in the #release-post Slack channel. Be sure to include the live URL link.

7. Share the links to the post in #whats-happening-at-gitlab in Slack.

8. Merge (or request a maintainer to merge) the "What's New" MR after the images referenced in that MR have been checked to load correctly locally.

9. Create the duplicate "What's New" MR for the release branch following the handbook instructions.

After the MR is merged

1. 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.

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

1. The post is to be live on the release day at 15:00 UTC. It should be merged 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 after all packages are publicly available. Not before. Ideally, merge it around 14:20 UTC as the pipeline takes about 40 min to run.
2. 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.
3. 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.
4. After the release post is live, wait a few minutes to see if anyone spots an error (usually posted in the #whats-happening-at-gitlab or #company-fyi channels), then follow the handoff to social team checklist item above.
5. The tweet to share on Slack will not be live, it will be scheduled during a peak awareness time on the release day. After the tweet is live, the social team will share the tweet link in the #release-post and #whats-happening-at-gitlab Slack channels.