Release post - GitLab 12.0

Process improvements? Have suggestions for improving the release post process as we go? Please capture them in the retrospective issue!

Review Apps: https://release-12-0.about-src.gitlab.com/2019/06/22/gitlab-12-0-released/

Release post:

• Intro: https://gitlab.com/gitlab-com/www-gitlab-com/blob/release-12-0/source/posts/2019-06-22-gitlab-12-0-released.html.md
• Items: https://gitlab.com/gitlab-com/www-gitlab-com/blob/release-12-0/data/release_posts/2019_06_22_gitlab_12_0_released.yml
• Images: https://gitlab.com/gitlab-com/www-gitlab-com/tree/release-12-0/source/images/12_0

Related files:

• Features YAML link: https://gitlab.com/gitlab-com/www-gitlab-com/blob/release-12-0/data/features.yml
• Features YAML Images link: https://gitlab.com/gitlab-com/www-gitlab-com/blob/release-12-0/source/images/feature_page/screenshots
• Homepage card: https://gitlab.com/gitlab-com/www-gitlab-com/blob/release-12-0/source/includes/home/ten-oh-announcement.html.haml
• MVPs: https://gitlab.com/gitlab-com/www-gitlab-com/blob/release-12-0/data/mvps.yml

Handbook references:

• Blog handbook: https://about.gitlab.com/handbook/marketing/blog/
• Release post handbook: https://about.gitlab.com/handbook/marketing/blog/release-posts/
• Markdown guide: https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/

People:

• Release Post Managers: https://about.gitlab.com/handbook/marketing/blog/release-posts/managers/
• Release Managers: https://about.gitlab.com/community/release-managers/

Release post manager	Tech writer	Messaging	Social
@jeremy	@eread	@johnjeremiah	@evhoffmann

General contributions

Due date: 2019-06-14 (6th working day before the 22nd)

All contributions added by team members, collaborators, and Product Managers (PMs).

Author's checklist

Due date: 2019-06-14 (6th working day before the 22nd)

The PM leading the post is responsible for adding and checking the following items: @jeremy

• Label MR: ~"blog post" release release post ~P1
• Assign the MR to yourself
• Add a release post retrospective issue (example) and provide a link to it at the top of this MR description with the text Process Improvements? Have suggstions for improving the release post process as we go? Capture them in the [Retrospective issue]().
• Check the reviewers on Slack and add their names (and your own) replacing each @mention in the MR description checklists
• Add milestone
• Update the links and due dates in this MR description
• Make sure the blog post have all initial files, as well as this MR template contains the latest template
• Add authorship (author's data)
• Ask the messaging lead to add the introduction by the 6th working day before the 22nd
• Add MVP (MVP block)
• Add MVP to data/mvps.yml
• Make sure the PM for the MVP feature adds a corresponding feature block if applicable, linking from the MVP section
• Add cover image (12_0-cover-image.jpg) (compressed)
• Add social sharing image (gitlab-12-0-released.png) (compressed)
• Make sure all feature descriptions are positive and cheerful
• Make sure all features listed in the direction page are included in the post
• Mention the Distribution PM asking them if there's any relevant info to be added to the upgrade warning section. If not, delete the upgrade block in the relese post data file
• Mention managers to remind them to add their team performance improvements: @gitlab-com/backend-managers and @gitlab-org/frontend/frontend-managers
• Check with the Messaging Lead on what the top features should be.
• Check if deprecations are included
• Alert people one working day before each due date (post a comment to #release-post Slack channel)
• Make sure all images (png, jpg, and gifs) are smaller than 300 KB each
• Run the release post through an automated spell and grammar check
• Pull master into the release post branch and resolve any conflicts
• Perform the content review

Recurring blocks

Due date: 2019-06-14 (6th working day before the 22nd)

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

• Mention the below individuals after feature freeze
• Add GitLab Runner improvements: @brendan
• Add Omnibus improvements: @ebrinkman
• Add Mattermost update to the Omnibus improvements section: @ebrinkman
• Add Performance improvements: @DouweM, @smcgivern, @ayufan

Feature blocks

Due date: 2019-06-14 (6th working day before the 22nd)

The Product Managers are responsible for adding their feature blocks to the release post by the due date for general contributions. PMs are also responsible for adding any notable Community Contributions.

PMs: please check your box only when all your features and deprecations were added with completion (documentation links, images, etc). Pls don't check if there are still things missing.

Note: 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.

• Mention the below individuals after feature freeze
• Manage (@jeremy)
• Plan (@ebrinkman)
• Create:Source Code (@jramsay)
• Create:Knowledge (@phikai)
• Create:Editor (@phikai)
• Verify (@brendan)
• Package (@trizzi)
• Release (@cstasik)
• Secure (@NicoleSchwartz )
• Configure (@danielgruesso)
• Monitor - APM (@kencjohnston)
• Monitor - Debug & Health (@sarahwaldner)
• Fulfillment (@tipyn)
• Distribution (@ebrinkman)

Tip: make your own checklist:

• Primary features
• Improvements (secondary features)
• Deprecations
• Documentation updated
• Documentation links added to the post
• Community contributions documented and added to the post
• Illustrations added to the post (compressed, max width = 1000 pixels)
• Update features.yml (with accompanying screenshots)

Review

Ideally, complete the review until the 4th working day before the 22nd, so that the 3rd and the 2nd working day before the release could be left for fixes and small improvements.

Content review

Due date: 2019-06-17 (5th working day before the 22nd)

Performed by the author of the post: @jeremy

• Label MR: ~"blog post" release review-in-progress
• Check all comments in the thread (make sure no contribution was left behind)
• Check Features' names
• Check Features' availability (Core, Starter, Premium, Ultimate badges)
• Reorder primary and secondary features according to their relevance to the user (most impactful features come first)
• Check Documentation links (all feature blocks contain documentation_link)
• Make sure documentation_link links to feature webpages when available
• Features were added to data/features.yml (with accompanying screenshots)
• Check all images size < 300KB (compress them all with TinyPNG or similar tool)
• Pull master, resolve any conflicts
• Make sure all discussions in the thread are resolved
• Mention @markpundsack, @kencjohnston, @jlenny, and @ebrinkman to remind them to review
• Assign the MR to the next reviewer (structural check)
• Lock features.yml with File Locking on the 21st

Structural check

Due date: 2019-06-19 (3rd working day before the 22nd)

The structural review is performed by a technical writer: @eread

• Add the label review-structure
• Pull master into the release post branch and resolve any conflicts
• Check frontmatter (entries, syntax)
• Check image_title and twitter_image
• Check image shadow applied correctly in release post data. Look for image_noshadow: true when an image already has shadow
• Ensure videos and iframes are wrapped in <figure class="video_container"> tags (for responsiveness)
• Ensure all text is consistently hard wrapped at a suitable column boundary
• Check headings are in sentence case
• Check feature and product names are in capital case
• Check if images are harmonic/consistent
• Check any .gitkeep files and delete them if any
• Add or check cover img reference (at the end of the post). Data in cover_img in release post Yaml file
• Ensure content is balanced between the columns (both columns are even)
• Ensure links have meaningful text for SEO (e.g., "click here" is bad link text)
• Check for badges consistency (applied to all headings)
• Double check that all features are documented
• Check that all links to about.gitlab.com content are relative URLs
• 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
• Remove any remaining instructions (comments) from the release post files
• Run a dead link checker, e.g., Check my Links and ping reporters directly on Slack asking them to fix broken links
• Update the release post templates and release post handbook with anything that comes up during the process
• Pull master into the release post branch and resolve any conflicts (again)
• 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 that no one will pay attention to. If possible, ensure any issues are tracked by open discussions in the merge request
• Post a comment in the #company-announcements channel linking to the review app + merge request reminding the team to take a look at the release post and to report problems in #release-post. Template to use (replace links):

  Hey all! This month's release post is almost ready! Take a look at it and report any problems in #release-post.
  MR: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/1234
  Review app: https://release-12-0.about-src.gitlab.com/2019/06/22/gitlab-12-0-released/

• Remove the label review-structure.
• Assign the MR to the next reviewer (Marketing).

Further reviews

Due date: 2019-06-20 (2nd working day before the 22nd)

• Marketing review (PMMs - messaging lead): @johnjeremiah
  • Write the introduction (by the 6th working day before the 22nd)
  • Check/copyedit feature blocks
  • Check/copyedit features.yml
  • Check/copyedit homepage blurb
  • Check/copyedit social sharing text
  • Mention Mark P (@markpundsack) for final check
  • Remove the label review-in-progress
  • Assign the MR back to the author

On the 22nd

The author of the post is responsible for merging the MR and following up with possible adjustments/fixes: @jeremy.

At 12:00 UTC

• Read the important notes below
• At ~12:30 UTC, ping the release managers on the #releases Slack channel asking if everything is on schedule, and to coordinate timing with them:
  • If anything is wrong with the release, or if it's delayed, you must ping the messaging lead on #release-post so that they coordinate anything scheduled on their side (e.g., press releases, other posts, etc).
  • If everything is okay, the packages should be published at 13:30 UTC, and available publicly around 14:10 UTC.
  • Ask the release managers to ping you when the packs are publicly available (and GitLab.com is up and running on the release version)
• Mention @sumenkovic to remind him to send the swag pack to the MVP
• Check if all the anchor links in the intro are working
• Check if there are no broken links in the review app (use a dead link checker, e.g., Check my Links)
• Pull master and fix any conflicts
• Check if there isn't any alert on Slack's #release-post and #company-announcements channels
• Check if there isn't any alert on this MR thread
• Check if the tweet copy is ready and someone is ready to share on social media

At 13:50 UTC

• Check if there aren't any conflicts. If there are any, pull master again and fix them.

Once the release manager confirmed that the packages are publicly available:

• Unlock features.yml just before merging.
• Verify that the 11.0 to 12.0 YT video has been made public: "It's still unlisted on YT, so we need to be sure to make it public just before the post goes live."
• Merge the MR at 14:10-14:20 UTC.
• Wait for the pipeline. It should take ~40min to complete.
• Check the look on social media with Twitter Card Validator and Facebook Debugger.
• Check for broken links again once the post is live.
• Share on social media (or make sure someone else does) only when you're sure everything is okay.
• Share the links to the post and to the tweet on the #release-posts and #company-announcements on Slack.

@dsumenkovic [is helping with the tweet](https://gitlab.slack.com/archives/C3TRESYPJ/p1560896427173700?thread_ts=1560894427.167300&cid=C3TRESYPJ when we go live, @evhoffmann is on the LinkedIn and FB posts at 9a Pacific. Thank you both very much for the help.

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 post is live, wait a few minutes to see if no one spot an error (usually posted in #company-announcements), then share on Twitter, Facebook, and LinkedIn, or make sure someone (Emily vH, JJ, Marcia) does. Coordinate the social sharing with them beforehand.
• Keep an eye on Slack and in the blog post comments for a few hours to make sure no one found anything that should be fixed.

data/release_posts/2019_06_22_gitlab_12_0_released.yml

+###
+#
+# Release post data file
+#
+# Start the release post with this file, named `YYYY_MM_22_gitlab_X_Y_released.yml`
+# placed into `data/release_posts/`.
+#
+# Notes:
+#  - All description entries support markdown. Use it as you do for a regular markdown file.
+#   Just make sure the indentation is respected.
+#
+## Entries:
+#
+# - name: Amazing Feature # feature name: make it consistent, use the same name here, in the features.yml file, and in the docs
+# - available_in: [core, starter, premium, ultimate]
+# - gitlab_com: false # apply this for features not available in GitLab.com
+# - documentation_link: 'https://docs.gitlab.com/ee/user/project/operations/feature_flags.htmldoc' # up-to-date documentation - required
+# - image_url: '/images/x_y/feature-a.png'
+# - image_noshadow: true # this eliminates double shadows for images that already have a shadow
+# - video: # overrides image_url - use the "embed" link
+# - reporter: pm1 # GitLab handle of the user adding the feature block in the list (not the feature author)
+# - stage: stagename # DevOps stage the feature belongs to
+#                      Example => stage: secure
+#                        lowercase, omit the leading 'devops::' part of the label
+#                        see https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/contributing/issue_workflow.md#stage-labels
+# - issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/12345' # link to the issue on GitLab.com where the feature is discussed and developed - required but replaceable with epic_url or mr_url
+# - issueboard_url: 'https://gitlab.com/group/project/boards/123?=' # link to the issue board for the feature (not required)
+# - epic_url: 'https://gitlab.com/groups/gitlab-org/-/epics/123' # link to the epic for the feature (not required)
+# - mr_url: 'https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/123' # link to the MR that introduced the feature (not required)
+# - webpage_url: '/features/gitlab-geo/' # link to the marketing webpage for a given feature (not required)
+#
+# Read through the Release Posts Handbook for more information:
+# https://about.gitlab.com/handbook/marketing/blog/release-posts/
+#
+# ATTENTION: Leave these instructions and the example blocks (with their inline comments) up until the time the review starts. Once you've added an item, and **only by then**, please remove the inline comment to indicate that the item has been updated, thus we can clear up the comments on the go and easily spot what's missing.
+###
+
+features:
+# TOP FEATURE
+  top:
+    - name: "Amazing Feature"
+      available_in: [starter, premium, ultimate] # required
+      gitlab_com: false # required if the feature is NOT available in GitLab.com. Else, delete this line.
+      documentation_link: "https://docs.gitlab.com/ee/user/project/operations/feature_flags.html" # required
+      image_url: "/images/9_X/feature-a.png" # required
+      reporter: pm1 # required
+      stage: secure # required if the feature belongs to a DevOps stage.
+      issue_url: "" # required
+      description: | # supports markdown
+        Lorem ipsum dolor sit amet, consectetur adipisicing elit. Aliquid laudantium,
+        quisquam pariatur architecto quo vel sequi, aperiam ex autem itaque saepe
+        sint dignissimos, quis voluptates similique.
+        Hic veritatis facere eligendi, minus nisi eveniet delectus fugiat.
+
+        Lorem ipsum dolor sit amet, `consectetur adipisicing` elit.
+        Rerum nisi et ex rem, obcaecati, commodi incidunt fugit,
+        deleniti nesciunt aperiam consequuntur.
+
+        1. Lorem ipsum dolor.
+        1. Lorem ipsum dolor sit.
+
+        > Lorem ipsum dolor sit amet.
+
+        Lorem ipsum dolor sit amet, [consectetur adipisicing elit](#link).
+        Quae repellat, at ullam amet.
+
+        ![Amazing feature screenshot](/images/X_Y/amazing-feature.png){:.shadow}
+
+        Lorem ipsum dolor sit amet, consectetur adipisicing elit.
+
+# PRIMARY FEATURES
+  primary:
+    - name: "Lorem ipsum"
+      available_in: [core, starter, premium, ultimate] # required
+      gitlab_com: false # required if the feature is NOT available in GitLab.com. Else, delete this line.
+      documentation_link: "https://docs.gitlab.com/ee/user/project/operations/feature_flags.html" # required
+      image_url: "/images/X_Y/feature-a.png" # required
+      video: "https://www.youtube.com/embed/enMumwvLAug" # example - optional - overrides image_url
+      reporter: pm1 # required
+      stage: plan # required if the feature belongs to a DevOps stage.
+      issue_url: "" # required
+      description: | # supports markdown
+        To ensure the appropriate secure method when integrating Feature Flags with your application token rotation and encryption will be enabled method added in this release.
+
+    - name: "Lorem ipsum"
+      available_in: [core, starter, premium, ultimate] # required
+      gitlab_com: false # required if the feature is NOT available in GitLab.com. Else, delete this line.
+      documentation_link: "https://docs.gitlab.com/ee/user/project/operations/feature_flags.html" # required
+      image_url: "/images/X_Y/feature-a.png" # required
+      video: "https://www.youtube.com/embed/enMumwvLAug" # example - optional - overrides image_url
+      reporter: pm1 # required
+      stage: verify # required if the feature belongs to a DevOps stage.
+      issue_url: "" # required
+      description: | # supports markdown
+        To ensure the appropriate secure method when integrating Feature Flags with your application token rotation and encryption will be enabled method added in this release.
+
+    - name: Visual Review Tools
+      available_in: [premium, ultimate]
+      documentation_link: ''
+      image_url: "/images/12_0/visual-review-apps.png"
+      reporter: brendan
+      stage: verify
+      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/10761'
+      description: |
+        GitLab gives users the ability to automatically create [review
+        apps](https://docs.gitlab.com/ee/ci/review_apps/) for each merge request. 
+        This allows anyone to see how the design or UX has been changed.
+
+        In GitLab 12.0 we are expanding the ability to discuss those changes by
+        bringing the ability to insert [visual review tools](https://gitlab.com/gitlab-org/gitlab-ee/issues/10761) 
+        directly into the Review App itself.  With a small code snippet, users can enable
+        designers, product managers, and other stakeholders to quickly provide
+        feedback on a merge request without leaving the app.  
+
+# SECONDARY FEATURES
+  secondary:
+    - name: "Lorem ipsum"
+      available_in: [premium, ultimate] # required
+      gitlab_com: false # required if the feature is NOT available in GitLab.com. Else, delete this line.
+      documentation_link: "https://docs.gitlab.com/ee/user/project/operations/feature_flags.html" # webpage or documentation - required
+      image_url: "/images/X_Y/feature-a.png" # optional - recommended
+      video: "https://www.youtube.com/embed/enMumwvLAug" # example - optional - overrides image_url
+      reporter: pm1 # required
+      stage: monitor # required if the feature belongs to a DevOps stage.
+      issue_url: "" # required
+      description: | # supports markdown
+        To ensure the appropriate secure method when integrating Feature Flags with your application token rotation and encryption will be enabled method added in this release.
+
+        Lorem ipsum dolor sit amet, consectetur adipisicing elit.
+        Voluptate eveniet, adipisci earum sed harum nostrum
+        itaque beatae, repellat sunt unde.
+
+    - name: "Add AND and OR operators for variable expressions in GitLab CI/CD"
+      available_in: [core, starter, premium, ultimate] # required
+      documentation_link: "https://docs.gitlab.com/ee/ci/variables/#supported-syntax" 
+      #image_url: "/images/X_Y/feature-a.png" # optional - recommended
+      reporter: brendan
+      stage: verify
+      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/62867"
+      description: | # supports markdown
+        Variable expressions provide powerful primitives for users to control when jobs run or not within a GitLab CI/CD pipeline.  
+        Featuring syntax that allows for equality, undefined values, empty variables, and even comparison between variables allows 
+        for fine grain control over job execution using variables and regular expressions.  
+        
+        With GitLab 12.0, this powerful primitive is extended to include AND (`&&`) and OR (`||`) operators to allow users 
+        to be explicit with conjunction logic in variable expressions.
+    
+    - name: "Add multiple extends support to GitLab CI/CD"
+      available_in: [core, starter, premium, ultimate] # required
+      documentation_link: "https://docs.gitlab.com/ee/ci/yaml/#extends" 
+      #image_url: "/images/X_Y/feature-a.png" # optional - recommended
+      reporter: brendan
+      stage: verify
+      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/53134"
+      description: | # supports markdown
+        Extends allows users to keep their GitLab CI/CD code [dry](https://dev.to/michalbryxi/how-to-dry-your-gitlab-ciyml-16pc).  
+        Using extends to condense common sections of code is a frequently used feature for advanced users of GitLab CI/CD, 
+        and is used by our own teams to [build GitLab](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/.gitlab/ci/rails.gitlab-ci.yml) 
+        as well as our [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) features.  
+        
+        In GitLab 12.0, we're so happy to welcome a contribution from [Wolphin](https://gitlab.com/q_wolphin) to improve this feature 
+        by allowing users to include multiple extends snippets in a single job.  Thanks Wolphin!
+
+    - name: "E-mail notifications for broken master builds"
+      available_in: [core, starter, premium, ultimate] # required
+      documentation_link: "https://docs.gitlab.com/ee/api/services#pipeline-emails" 
+      image_url: "/images/12_0/failed-pipeline-email.png" 
+      reporter: brendan
+      stage: verify
+      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/61721"
+      description: | # supports markdown
+        The GitLab [Pipeline Emails](https://gitlab.com/gitlab-org/gitlab-ce/issues/61721) service integration allows users to create 
+        e-mail alerts on build completion and failure to a list of recipients.   
+        Previously, users could only subscribe to all build failures.  In GitLab 12.0, we have added the option to only 
+        send the failure notification on the default branch for the project (e.g. master).
+        
+        Thank you to [Peter Marko](https://gitlab.com/petermarko) for this contribution!
+
+    - name: "Improve support for passing variables to downstream pipelines"
+      available_in: [core, starter, premium, ultimate] # required
+      documentation_link: "https://docs.gitlab.com/ee/ci/multi_project_pipelines.html#passing-variables-to-a-downstream-pipeline" 
+      #image_url: "/images/X_Y/feature-a.png" # optional - recommended
+      reporter: brendan
+      stage: verify
+      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/60716"
+      description: | # supports markdown
+        In GitLab 11.8, we introduced the ability to [trigger](https://docs.gitlab.com/ee/ci/multi_project_pipelines.html#triggering-a-downstream-pipeline-using-a-bridge-job) 
+        a downstream pipeline from an upstream bridge job.  
+        We also introduced basic support for passing variables to the downstream pipeline.  
+        However, with GitLab 12.0 we support passing current environmental variables to the downstream pipeline as well.  
+        This allows users to provide context to the downstream pipeline as to the commit, 
+        merge request or other details from the pipeline that triggered it.
+
+    - name: "Default shallow clones for all new projects in GitLab CI/CD"
+      available_in: [core, starter, premium, ultimate] # required
+      documentation_link: "https://docs.gitlab.com/ee/user/project/pipelines/settings#git-shallow-clone" 
+      #image_url: "/images/12_0/X.png" 
+      reporter: brendan
+      stage: verify
+      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/59688"
+      description: | # supports markdown
+        Since GitLab 8.9, GitLab CI/CD has supported shallow [git clones](https://git-scm.com/docs/git-clone#Documentation/git-clone.txt---depthltdepthgt) by specifying the `GIT_DEPTH` variable in your job definition. 
+        In GitLab 12.0, we've added the ability to set this depth at the project level - enabling project maintainers to default to 
+        a shallow clone if desired.  Shallow git clones are faster than cloning the entire git repository every time, 
+        and if your CI/CD jobs are set up to build the latest, often a shallow clone is sufficient.
+        
+        Also in GitLab 12.0, new projects created in GitLab will - by default - have a `GIT_DEPTH` setting of `50` when they are created.  
+        This sensible default will help users have faster clone and build times with GitLab CI/CD, 
+        while still allowing advanced users to change this setting if required for different types of CI/CD use cases.
+
+    - name: "Enable dependency proxy per group by default"
+      available_in: [premium, ultimate] # required
+      gitlab_com: false # required if the feature is NOT available in GitLab.com. Else, delete this line.
+      documentation_link: "https://docs.gitlab.com/ee/user/group/dependency_proxy/" # webpage or documentation - required
+      image_url: "/images/12.0/group_dependency_proxy.png" # optional - recommended
+      reporter: tim # required
+      stage: package # required if the feature belongs to a DevOps stage.
+      issue_url: "https://gitlab.com/gitlab-org/gitlab-ee/issues/11638" # required
+      description: | # supports markdown
+        In GitLab 11.11, we launched the MVC of the [dependency proxy](https://docs.gitlab.com/ee/user/group/dependency_proxy/), which allows users to download and cache Docker images for faster, more reliable downloads. 
+        In GitLab 12.0, we have enabled the feature by default at the group level. For more information about the dependency proxy, please visit our [category strategy page.](https://about.gitlab.com/direction/package/dependency_proxy/)
+
+    - name: "Update Maven template to automatically build and push to the Maven Repository"
+      available_in: [premium, ultimate] # required
+      documentation_link: "https://docs.gitlab.com/ee/user/project/packages/maven_repository.html" # webpage or documentation - required
+      reporter: tim # required
+      stage: package # required if the feature belongs to a DevOps stage.
+      issue_url: "https://gitlab.com/gitlab-org/gitlab-ee/issues/10051" # required
+      description: | # supports markdown
+        Java developers need an easy way to build and manage their dependencies with GitLab's CI/CD pipelines.
+        In 12.0, we have modified the existing `Maven.gitlab-ci.yml` template to allow users to upload and manage their Java dependencies to the GitLab Maven Repository from their CI/CD pipelines. 
+
+# Omnibus and performance (required)
+
+    - name: "Omnibus improvements"
+      available_in: [core, starter, premium, ultimate]
+      gitlab_com: false
+      documentation_link: "https://docs.gitlab.com/omnibus/"
+      reporter: pm1 # required
+      description: | # supports markdown
+        To ensure the appropriate secure method when integrating Feature Flags with your application token rotation and encryption will be enabled method added in this release.
+
+    - name: "Performance improvements"
+      available_in: [core, starter, premium, ultimate]
+      performance_url: https://gitlab.com/groups/gitlab-org/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&label_name%5B%5D=performance&milestone_title=12.0 # Link to the merged MRs in the corresponding milestone
+      reporter: multiple # required
+      description: | # supports markdown
+        We continue to improve the performance of GitLab with every release
+        for GitLab instances of every size. Some of the improvements in GitLab
+        12.0 are:
+
+        - [Make epics list page more efficient](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/13904)
+        - [Avoid hitting the database for Elasticsearch results](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/12691)
+        - [Avoid hitting Elasticsearch twice for search results](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/13120)
+        - [Improve performance when loading an issue or merge request with a long description](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/28597)
+
+# EXTRAS (Optional)
+# extras:
+#  - title: "Hello World"
+#    description: | # supports markdown
+#     Lorem ipsum dolor sit amet, consectetur adipisicing elit. Consequuntur, beatae!
+
+# MVP
+mvp:
+  fullname: "" # Name Surname
+  gitlab: # gitlab.com username
+  description: | # example (supports markdown)
+    Lorem ipsum [dolor sit amet](#link), consectetur adipisicing elit.
+    Perferendis nisi vitae quod ipsum saepe cumque quia `veritatis`.
+
+# COVER IMAGE LICENCE
+cover_img:
+  image_url: "https://example.com#link_to_original_image" # required
+  licence: CC0 # which licence the image is available with - required
+  licence_url: "#https://example.com#link_to_licence" # required
+
+# CTA BUTTONS (optional)
+# Tip: You can add more than one.
+cta:
+  - title: "Join us for an upcoming event" # default
+    link: '/events/'
+
+# UPGRADE WARNING (optional)
+# https://about.gitlab.com/handbook/marketing/blog/release-posts/#important-notes-on-upgrading
+upgrade:
+  reporter: pm1 # required
+  description: | # example (supports markdown)
+    Use this section to describe important notes for upgrading GitLab to the
+    current version. If there's nothing relevant to a given release, delete
+    this section.
+
+# DEPRECATIONS (optional)
+# include as many deprecation blocks as necessary
+deprecations:
+  - feature_name: "Lorem ipsum dolor"
+    due: May 22nd, 2017. # example
+    reporter: pm1 # required
+    description: |  # example (supports markdown)
+      Lorem ipsum dolor sit amet, consectetur adipisicing elit.
+      Veritatis, quisquam.
+  - feature_name: "Lorem ipsum dolor"
+    due: May 22nd, 2017.
+    reporter: pm1 # required
+    description: |  # example (supports markdown)
+      Lorem ipsum dolor sit amet, consectetur adipisicing elit.
+      Veritatis, quisquam.