Gitlab hero border pattern left svg Gitlab hero border pattern right svg

GitLab Release Posts

Release posts

Release posts are blog posts that announce changes to the GitLab application. This includes our regular cadence of monthly releases which happen on the 22nd of each month, and patch/security releases whenever necessary.

Release posts follow a process outlined here, and the templates that are used to create them also highlight what needs to be done, by who, and when those items are due.


The sections below also link to these templates, but they're provided here for quick reference.

Monthly releases

Monthly releases are blog posts with an exclusive layout aiming to apprise the reader of the changes, new features, and other considerations for the new release that comes out on the 22nd of every month. They follow a process that involves collaboration across many different roles, and each persona's responsibilities are outlined on this page.

At a high level, the process is:

Date Step
By the 7th The Release Post Manager creates a branch on www-gitlab-com and MR in that project that will collect all the release post items in to a single blog entry
1st - 10th PMs contribute release post items as individual MRs that add the feature to features.yml and as a new item in /data/release_posts/unreleased.

PMs add recurring content blocks for Omnibus improvements, deprecation warnings, and more
by the 16th PMMs, TWs, and PM Directors review individual release post items MRs
by the 17th EMs merge those MRs in to master as the features they represent are merged in to the GitLab codebase

EMs add a recurring content block for performance improvements
18th of Month The Release Post Manager aggregates all the content by updating their branch from the master branch, then moving all the "unreleased" items in to the release post

The Release Post Manager chooses an MVP for the release and selects a cover image

The Messaging lead picks a top feature or features to highlight and creates that content
18th - 20th The Release post manager, Messaging Lead, and TW Lead perform reviews to ensure everything is ready to publish
22nd of Month The Release post manager, publishes the blog post to master on the morning of the 22nd, immediately following the package itself being published by the Release team

Note: The specific steps that should be followed, when they are due, and the order they should be followed in are described in the Monthly release post MR template and the Monthly release post item MR template.


Release Post Manager

Each month a Product Manager will lead the release post, as defined in the Release Post Scheduling page. The Release Post Manager is listed as the Author of the release post when the post is published.

Product Managers can volunteer for any release that doesn't have someone assigned yet. Otherwise, they will be assigned using a fair scheduling principle:

  1. Members that never managed a release post before
  2. Members that have the longest interval since they managed their last release post

After joining the company, there is a grace period of a few months where the new Product Manager will get up to speed with the process, then they will be scheduled to manage a release post.

Adding members to the list is a shared task, and everyone can contribute by following the principle described above. Scheduled people are pinged in the merge request to make them aware. They don't need to confirm or approve, since they can always update the list if they are not available for the given release post.

Important: if you're scheduled for a given month and you can't make it, because you're on vacation, overloaded, or for any other reason, that is okay, as long as you swap the release post manager role with someone else before creating the merge request and starting the whole process. If you take it, you're responsible for the entire process and must be available to carry it out until the end.

The Release Post Manager is accountable for:

Important: Please check beforehand if you have merge rights to the www project. If you don't, ask someone to grant you access or pair with someone else to merge the post with you on the 22nd. If someone else merges it, make sure you're available to follow up with anything that might come up in the last minute.

Create your release post branch

Note: In the following sections we refer to the GitLab version as X.Y and the date of the release as YYYY/MM/22. You should replace those values with the current version and date. The day will always be the 22nd, so no need to change that.

There are two ways to create the initial monthly release post in the repository: a) using a script and b) manually. The script does exactly what you would manually, but automates the process.

First way: using a script
  1. Make sure you have set everything up to contribute to the repository.
  2. Locally in a terminal run the script replacing the version:

    bundle exec rake "release:monthly[12.10]"
  3. Push the branch that was created and follow the link to create the merge request.
Second way: manually

The manual way can be done either locally or using the GitLab Web IDE:

  1. Create a new branch release-X-Y.
  2. Create the blog post file, containing the introduction and the blog post frontmatter information:
    1. In the source/releases/posts/ directory, add a new file called by copying the monthly release blog template.
  3. Create the release post data directory, to which features and other data will be added:
    1. Create a new directory X_Y in the data/release_posts directory.
    2. Copy data/release_posts/unreleased/samples/upgrade_notes.yml into data/release_posts/X_Y/upgrade_notes.yml.
    3. Copy data/release_posts/unreleased/samples/mvp.yml into data/release_posts/X_Y/mvp.yml.
    4. Copy data/release_posts/unreleased/samples/cta.yml into data/release_posts/X_Y/cta.yml.

Important! Please use the most recent templates for each of these files. They can be found when browsing the repository in the master branch.

Create the release post MR

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:

  1. The branch name must be release-X-Y.
  2. Set the title to WIP: Release post - GitLab X.Y.
  3. Confirm that "Remove source branch when merge request is accepted" is selected.
  4. Use the release post template for your MR.

    release post MR template

Important: all the files related to the release process, including data/features.yml, data/mvps.yml and source/includes/home/ten-oh-announcement.html.haml must be committed in this MR.

Merge individual items in to your branch

When it is time to assemble the release post, this will be done by moving the content block files from data/release_posts/unreleased to data/release_posts/X_Y.

Those block items comprise of the release post items that each PM creates for each feature.

TODO: Mention script in


The release post manager, the Messaging lead and the TW lead will need to communicate about topics that are related to the release post but not relevant to all participants in the main Slack release post channel. The Release Post Manager will create a Slack channel called "X-Y-release-post-prep to faciliate communication specific to the release post leads, which will be utilized till the 21st to minimize noise in the main release post Slack channel. On the 22nd, this channel will be abandoned and all communication will default to the main release post Slack channel for the final day of collaboration.


The review is performed after content has been added, so it's important to respect the due dates, otherwise reviews will have to be done repeatedly.

The review should be completed until the 2nd working day before the 22nd, so that the 1st working day before the release should be left for fixes and small improvements.

The due dates for each review can be found on the MR description.

Content review

The content review is performed by the Release Post Manager, who will check if everything is in place, and if there's nothing missing. Will also make suggestions, ask questions, and make sure all the comments are solved (ping people on Slack if necessary). Also, assure all items in the "general contributions" list presented in the MR description have been checked.

Lastly, the post should be reviewed by a Marketing team member (PMM, CMM) to evaluate wording and messaging.

Follow the checklist on the MR description for every review item.

Updating Release Post Manager assignments

To update the release post managers list, edit the data file below.

PM Contributors

Product Managers are responsible for raising MRs for their content blocks and ensuring they are reviewed by necessary contributors by the due date. These are mostly added by the Product Managers, each filling up the sections they are accountable for, but anyone can contribute, including community contributors. Content blocks should also be added for any epics or notable community contributions that were delivered.

Contribution instructions

In parallel with feature development, a merge request should be prepared by the PM with the required content. Do not wait for the feature to be merged before drafting the release post item, it is recommended PMs write Release Post Item MRs as they prepare for the milestone Kickoff.

Key dates:


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.

When writing your content blocks, be sure to reference Writing release blog posts and Writing about features to ensure your release post item writeups align with how Gitlab communicates. This will also ensure a smoother and more speedy reivew process for your release post items.


PM Director/Group Manager and PMM reviews are highly recommended, but the Tech Writer review is the only one required for inclusion in the Release Post. The Tech Writing review should be focused on looking for typos, grammar errors, and helping with style. PMs are responsible for coordinating any significant content/tech changes. Communicating priority about which release post items are most important for review will help Product Section leads, PMMs, and Tech Writers review the right items by the 10th of each month, so ensure the proper labels ares applied to the MR and assign reviewers to the MR when it is ready for them to review (ex: Tech Writing, Direction, Deliverable, etc).

Recommendations for optional PM Director/Group Manager and PMM Reviews:

As Director and PMM reviews are not required, but recommended, PMs should consider a few things when determining which content blocks to request a review for:

If the answer to any of these is "yes", it is recommended that you coordinate with your Director and PMM to review the content block by the 16th. As the PM it is your responsibility to communicate what MRs need review from the TWs, PMMs, and Directors as well as the MRs relative priority if you have multiple content block MRs that need reviews.

Merging Content Block MRs

Engineering Managers are the DRIs for merging these MRs when the feature is merged in to the codebase itself. This allows all of the relevant parties (Product Managers, PMMs, Section Leads, Technical Writers) to have enough time to review the content without having to scramble or hold up engineering from releasing a feature.

To enable Engineering Managers to merge their feature blocks as soon as an issue has closed, please ensure all scheduled items you want to include in the release post have content blocks MRs created for them and have the Ready label applied when content contribution and reviews are completed.


You are responsible for the content you add to the blog post. Therefore, make sure that:

Write the description of every feature as you do to regular blog posts. Please write according to the markdown guide.

Important! Make sure to merge master into the release post branch before pushing changes to any existing file to avoid merge conflicts. Do not rebase, do git pull origin master then :wq.

PMs checklist

Once the PMs have included everything they're accountable for, they should check their item in the release post MR description:

PMs check list

By checking your item, you will make it clear to the Release Post Manager that you have done your part in time (during the general contributions stage) and you're waiting for review. If you don't check it, it's implicit that you didn't finish your part in time, despite that's the case or not.

Once all content is reviewed and complete, add the Ready label and assign this issue to the Engineering Manager (EM). The EM is responsible for merging as soon as the implementing issue is deployed to, after which this content will appear on the Release page and can be included in the next release post. All release post items must be merged on or before the 17th of the month. If a feature is not ready by the 17th deadline, the EM should push the release post item to the next milestone.

Notes for PMs


If you are on vacation before/during the release, fill all your items and create placeholders in the release post Yaml file for all the items you cannot add for whatever reason. To complete them, and to follow up with all the content you are responsible for, assign someone to take over for you and notify the Release Post Manager.


Please respond to comments in the MR thread as soon as possible. We have a non-negotiable due date for release posts.


Please add the documentation_link at the same time you add a content block to the release post. When you leave it to add it later, you will probably forget it, the reviewer will ping you later on during the review stage, and you will have little time to write, get your MR reviewed, approved, merged, and available in

Always link to the EE version of GitLab docs in the blog post, even if it is a CE feature.

Messaging lead

Each month a Product Marketing Manager (PMM) will lead the messaging and positioning for the release post.

The messaging lead is responsible for:

Top three features

This section provides guidance on how to decide on top 3 features or themes and timelines:

Best practices for the release post:

Feature order

Marketing coordination

PMM Reviewers

Messaging review

Each PM is responsible for pinging their PMM counterpart when they need a review on the messaging for a Release Post Item MR or changes to features.yml.

TW Lead

Structural check

Once assigned to the release post merge request, a technical writer, will check the syntax and the content structure.

Note: Technical writers review the individual release post items according to the stage/group they are assigned to. Each month, one of the technical writers is also responsible for the structural check of the final release post merge request. This section is about the latter.

The checklist in the main release post merge request description will guide them through the structural check.

Given that the technical writing review occurs in release post items' merge requests, the purpose of the structural check is:

Pay special attention to the release post markdown file, which adds the introduction. Review the introduction briefly, but do not change the writing style nor the messaging; these are owned by PMMs, so leave it to them to avoid unnecessary back-and-forths. Make sure feature descriptions make sense, anchors work fine, all internal links have the relative path.


In its frontmatter:

release_number: "X.Y"
title: "GitLab X.Y Released with Feature A and Feature B"
author: "Name Surname"
author_twitter: twitter-username
categories: releases
image_title: '/images/X_Y/X_Y-cover-image.ext'
description: "GitLab X.Y Released with XXX, YYY, ZZZ, KKK, and much more!"
twitter_image: '/images/tweets/gitlab-X-Y-released.jpg'
layout: release
featured: yes
# header_layout_dark: true #uncomment if the cover image is dark
# release_number_dark: true #uncomment if you want a dark release number


The last two entries of the post's frontmatter give the option for a different layout. If you want to use a dark cover image, you'll need to uncomment header_layout_dark: true.

If you want only the release number to be dark, uncomment release_number_dark: true.

These two variables work independently; you can assign either of them or both of them to the same post.

TW Reviewers

Note: TW reviewers should not be confused with the TW lead.

Each person of the Technical Writing team is responsible for the review of each individual release post item that falls under their respective stage/group.

When the PM creates the release post item merge request, they should assign to the TW of their group for review (required). The process of the TW review is described in the release post item template.

Engineering Managers

The responsibilities of the Engineering Manager are documented in the Engineering Handbook.

Monthly release blog post sections


The messaging lead writes the introduction for the release post.

Add the copy for the intro to the blog post file (, in regular markdown. This file linked at the top of the release post MR. E.g. GitLab 11.2 blog post file

Introductory paragraph


The first paragraph is the one that catches the eyes of the reader, it should be punchy giving a summary of the most significant features. This first paragraph can then be used as a summary on the homepage and on social media. It should catch attention and cause the reader to want to read more.

The following paragraphs should highlight the business value of top 3 features and link to the feature description (link using the feature headings' anchors). It's important to highlight the pain points solved and the value the feature provides.

A final paragraph can give a shout out to additional features encouraging the reader to read the full release notes to learn about all the features have that shipped. It should also include the total number of new features being released, including bugs, performance improvements, and contributions from non-DevOps stages like Enablement. All of these should be listed in the release post, either as headers or bullet points.

@mention the PMs whose features are included the intro and ask them to review.

Examples of previous release post intros written by PMM:


Call-to-action buttons displayed at the end of the introduction. A CTA to the events page is added by default. Add webcasts, or custom buttons to this entry whenever necessary.

  - title: Join us for an upcoming event
    link: '/events/'
  - title: Lorem ipsum dolor sit amet
  - link:


To display the MVP of the month, use the example provided in this template, and adjust it to your case. Don't forget to link to the MR with the MVP's contribution.

  fullname: Dosuken Shinya # full name
  gitlab: dosuken123 # username
  description: | # supports markdown. Please link to the MR with the MVP's contribution.
    Dosuken extended our [Pipelines API](
    by [adding additional search attributes](
    This is a huge improvement to our CI API, for example enabling queries to easily return the latest
    pipeline for a specific branch, as well as a host of other possibilities. Dosuken also made a great
    contribution last release, laying the foundation for
    [scheduled pipelines]( Thanks Dosuken!

Suggestions should be ideally added along the month into the #release-post channel, as soon as you see a contribution, or a set of contributions that you think are great and should be taken into consideration for the choice. Every GitLab team-member and core team member is encouraged to add suggestions to the channel, always linking to issues and merge requests.

Based on this discussion, the Release Post Manager will make a decision. They should not wait for consensus. There can only be one MVP.

The MVP will be prized with a gift from GitLab, usually a swag pack. :)

Important: the MVP section should briefly describe what the feature is about, link to the GitLab profile of the MVP, and link to the issue, MR, issue board, or epic that introduced the change that awarded by the MVP. If it is a major feature, it must be accompanied by a content block with a more detailed description linked from the MVP section. The MVP feature, as well as any other feature, regardless of who shipped it, must be documented and linked to the docs.

Important: remember to update data/mvps.yml with the new MVP.


The most relevant features of the release are included in the post by product managers. Classify the feature according to its relevance and to where you want to place it in the blog post:

Top feature

The most important feature of the release, mentioned right after the MVP section. Images can be added at will in the description entry. A link to the documentation is required.

Primary features

Features with higher impact, displayed in rows after the top feature, with an image next to its text. An image accompanying the description is required. A video can also be added to replace the image.

Secondary features (other improvements)

Relevant improvements in GitLab. Image is not required, but recommended.

Content blocks

Note: "Feature blocks" are now known as content blocks, as there are many that are not just features. For example, we include upgrade warnings, Omnibus installer improvements, and performance enhancements.

Use content blocks to add features or other content to the YAML data file. The layout will be applied automatically by Middleman's templating system.

Content blocks in the YAML data file contain the following entries, as exemplified below:

- name: "Multi-Project Pipeline Graphs"
  available_in: [premium, ultimate]
  documentation_link: ''
  image_url: '/images/9_3/multi-project_pipelines.png'
  reporter: bikebilly
  stage: secure
    - "Application Security Testing"
    - "SAST"
  issue_url: ''
  description: |
    Lorem ipsum dolor sit amet, [consectetur adipisicing](#link) elit.

Feature name

Use a short and strong name for all feature names.

Feature Availability

Use the following pattern to apply the correct badge to the feature (Core, Starter, Premium, Ultimate).

If the feature is available in, the badges for will be applied automatically according to the self-managed availability. For example, available_in: [premium, ultimate] will "turn on" the badges Premium, Ultimate, Silver, and Gold.

If the feature is not available in, e.g., LDAP and admin settings, use the tag gitlab_com: false to turn off the entire badges' row. For example, for GitLab Geo features, use:

available_in: [premium, ultimate]
gitlab_com: false

If the feature is only available in, e.g. subscriptions, you can use the following badges:

If, however, the feature is only available on because it is behind a feature flag and disabled by default, it should not be included in the release post unless you are deliberately seeking beta testers.


Provide a link to the updated documentation for the feature. It is a required field. It can be, in this priority order:

Important: always link to the EE documentation, even if the feature is available in CE.

Note: documentation_text was deprecated by !13283 for GitLab 11.2.

Important: Every feature mentioned on the release post must link to an up-to-date document shipped in time, before the feature freeze. "Docs or it didn't happen!"

Illustration (images, videos)

Check the section Adding Content > Illustrations for more information.

Feature reporter


The stages display as an icon next to the product tiers' badges linking to the stage webpage using a regex:<stage>/. We can also override it with a custom stage URL.

Although stage is a required field, if a feature doesn't belong to any of the stages at all, you can delete the stage line and it won't output anything.

Besides displaying the icon, with stage set, PMs can easily find anything that is related to their area, even if reported by other users.

Note: team was deprecated in December 2018 for GitLab 11.6 in favor of stage, with a follow-up iteration introducing their respective icons.

Custom stage URL

For stages outside of the DevOps lifecycle, such as Enablement and Growth, which don't have the same path as the other stages (/stages-devops-lifecycle/<stage>), it is necessary to add the stage_url to the content block to override the default path:

# Enablement
stage: enablement
stage_url: '/handbook/engineering/development/enablement/'

# Growth
stage: growth
stage_url: '/handbook/product/growth/'


Feature description

Cover image license

According to our Blog handbook, it's necessary to provide the source of the cover image. Fill in the entry below to display this info at the very end of the blog post:

  image_url: '#link_to_original_image'
  licence: CC0 # which licence the image is available with
  licence_url: '#link_to_licence'

Important notes on upgrading

The "upgrade barometer" section was deprecated on GitLab 11.8 and replaced with a section called "Important notes on upgrading to GitLab X.Y".

Upgrade warnings should be added to the release post only to describe important upgrade notes, such as:

If there's no relevant info to a given release, do not add this section to the post.

Performance improvements

To be added by the engineering leads.

Describes relevant performance improvements individually, when present. Otherwise, you can either use this standard redaction or write a new one:

    - name: Performance Improvements
      available_in: [core, starter, premium, ultimate]
      performance_url:[]=performance&milestone_title=X.Y # merged MRs in the corresponding milestone
      reporter: bikebilly
      description: |
        We are continuing to make great strides improving
        the performance of GitLab in every release.
        [We're committed](/handbook/product/#performance) to not only
        making individual instances of GitLab even faster,
        but also to greatly improving the performance of,
        an instance that has over 1 million users!

        In GitLab X.Y we are shipping performance
        improvements for issues, projects, milestones, and a lot more!

        Some of the improvements in GitLab X.Y are:

        - [Feature summary](url of MR/Issue)

Don't forget to replace X.Y above with the current release!

Omnibus improvements

To be added by the Distribution Product Manager.

This section should contain any relevant updates for packaged software, new features, and new commands relating to the administration of self-managed GitLab instances deployed using the Omnibus package e.g. (gitlab-backup).


If you need an extra block to convey important info, and it doesn't fit the other blog post sections, you can use the extras block, right before deprecations (in the release post YAML datafile):

  - title: "Hello World"
    description: | # supports markdown
      Lorem ipsum dolor sit amet, consectetur adipisicing elit. Consequuntur, beatae!

For more multiple blocks, use:

  - title: "Hello World"
    description: | # supports markdown
      Lorem ipsum dolor sit amet, consectetur adipisicing elit. Consequuntur, beatae!
  - title: "Lorem"
    description: | # supports markdown
      Lorem ipsum dolor sit amet, consectetur adipisicing elit. Doloremque.


Describe the deprecations happening on that release or in upcoming releases. Let our community know about a future deprecation as soon as possible. When adding deprecations be sure to keep with the same structure of "XYZ feature or function will be deprecated at ABC time."

The due date is defined by the removal of that feature. The field is required, and should be set as:

  - feature_name: Lorem ipsum dolor
    due: May 22nd, 2017 # example
    reporter: bikebilly # item author username
    description: |  # example (supports markdown)
      Lorem ipsum dolor sit amet, consectetur adipisicing elit.
      Veritatis, quisquam.

For multiple deprecations, use multiple feature deprecation blocks:

  - feature_name: Lorem ipsum dolor
    due: May 22nd, 2017 # example
    description: |  # example (supports markdown)
      Lorem ipsum dolor sit amet, consectetur adipisicing elit.
      Veritatis, quisquam.
  - feature_name: Lorem ipsum dolor
    due: May 22nd, 2017. # example
    description: |  # example (supports markdown)
      Lorem ipsum dolor sit amet, consectetur adipisicing elit.
      Veritatis, quisquam.

Adding content

For entries that support markdown, use regular markdown Kramdown, as we use for all blog posts and webpages on




You can add YouTube videos to content blocks that can either override the image or add it within the markdown description as described below.

Videos in content blocks

For content blocks, you can add a video instead of an image by using the entry video:. If both are present, the video will override the image (it won't display the image, only the video). Example:

- name: "Awesome Feature"
  available_in: [premium, ultimate]
  documentation_link: 'doc-link'
  video: ""
  description: |
    Lorem ipsum dolor sit amet, consectetur adipisicing elit. Quae, provident.

Make sure to add the /embed/ video URL from YouTube. Follow the steps described on the markdown guide to find the correct path.

Videos added to the description

When added to a markdown-supported entry, every video should be wrapped into a figure tag, as shown below:

- name: "Awesome Feature"
  description: |
    Lorem ipsum dolor sit amet, consectetur adipisicing elit. Quae, provident.

    <!-- Leave a blank line above and below the code below. Do not change the code block in any ways, except for the video URL. Leave the indentation as-is and do not remove the whitespace before </iframe>. Remove this comment when ready. -->

    <figure class="video_container">
      <iframe src="" frameborder="0" allowfullscreen="true"> </iframe>

    Lorem ipsum dolor sit amet, consectetur adipisicing elit. Quae, provident.

The <figure> element is recommended for semantic SEO and the video_container class will assure the video is displayed responsively.

Consult the markdown guide for the correct markdown markup to apply to different sources (YouTube, Google Drive, HTML video).

Technical aspects

The release post is created from many small data files, that are rendered into the final form using templates and helpers.

The content files need to be created every release with the content unique to that release, as described by the section getting started.

The template and helper files are used to render the blog post from the many content files, and do not need to be changed in most releases.

To learn more how the template system works, read through an overview on Modern Static Site Generators.

Release post item generator

The release post item generator can help you create release post items quickly from your local command line.

To use the generator, after cloning the www-gitlab-com project to you computer:


>> Please specify the index for the category of release post item:
1. Top feature
2. Primary feature
3. Secondary feature
4. Deprecation

?> 3

create data/release_posts/unreleased/test-feature.yml
  - name: Review changes file-by-file in a merge request
    - core
    - starter
    - premium
    - ultimate
    gitlab_com: true
    image_url: "/images/unreleased/feature-a.png"
    reporter: jramsay
    stage: create
    - Code Review
    description: |
      Lorem ipsum [dolor sit amet](#link), consectetur adipisicing elit.
      Perferendis nisi vitae quod ipsum saepe cumque quia `veritatis`.

hint add a screenshot, commit, and push your changes!
    git add data/release_posts/unreleased/test-feature.yml
    git commit -m "Review changes file-by-file in a merge request
    git push -u origin

Release post item linting

The release post item linter validates all items being merged to the data/release_posts/unreleased directory meet minimal standards. Specifically, it checks:

It does not check if:

The schema is implemented using Rx.

Release post merge request template

The release post MR template is our checklist for every release. Let's keep it up-to-date! :)

Patch and Security release posts

The Delivery team is responsible for creating release posts for patch and security releases.

Release posts should live in source/releases/posts. For patch and security releases, please make sure to specify them in the title, add the correct category: