###
#
# 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/#amazingdoc' # 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: "Directed Acyclic Graphs (DAG) for GitLab Pipelines"
      available_in: [core, starter, premium, ultimate] # required
      documentation_link: "https://docs.gitlab.com/ee/ci/directed_acyclic_graph/" # required
      image_url: "/images/12_2/directed-acyclic-graph.png" # required
      reporter: jyavorska # required
      stage: verify # required if the feature belongs to a DevOps stage.
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/47063" # required
      description: | # supports markdown
        In a simple pipeline, you want all jobs in a stage to complete before moving to the next stage. Many pipelines have all tests should pass before starting to deploy. But with more complex pipelines you might want jobs in one stage to start before the previous stage has finished. For example, when a project generates both Android and iOS apps in a multi-stage pipeline, you likely want the iOS deployment to start as soon as all the iOS tests pass rather than waiting for all the Android tests to pass too.  The total compute time might be the same, but the wall-clock time is different.

        To address use cases like this and give you a powerful and flexible tool for defining complex pipelines we've added the `needs:` keyword for defining relationships between jobs in your `.gitlab-ci.yml`. The `needs` keyword lets you specify one job as a prerequisite for another job. Once the prerequisite job successfully completes, the job that depends on it in the next stage will kick off immediately without waiting for any other jobs in the previous stage to complete.

        In the internals of GitLab, we've implemented this functionality using a [Directed Acyclic Graph (DAG)](https://en.wikipedia.org/wiki/Directed_acyclic_graph). Essentially, when GitLab generates a pipeline from your configuration it's using a complex ruleset to determine the sequencing of your jobs rather than simply gating all jobs in a stage until the previous stage completes. This allows for much more efficient pipeline execution and lays a foundation for [more advanced capabilities on the way](https://gitlab.com/groups/gitlab-org/-/epics/1716). 
        
        You can get started with the `needs` keyword today for building pipelines like the example above as well as interesting new monorepo use cases where several unrelated services are kept in a single repository and don't all need to be built/wait for each other.
        
# PRIMARY FEATURES
  primary:
    - name: "Annotations for Designs"
      available_in: [premium, ultimate] # required
      documentation_link: "https://docs.gitlab.com/ee/user/project/issues/design_management.html" # required
      image_url: "/images/12_2/design-annotations.png" # required
      video: "https://www.youtube.com/embed/xksh3-WaglE" # example - optional - overrides image_url
      reporter: phikai # required
      stage: create # required if the feature belongs to a DevOps stage.
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ee/issues/9489"
      epic_url: "https://gitlab.com/groups/gitlab-org/-/epics/660" # required
      description: | # supports markdown
        Annotations for Designs allow Designers and Developers to more closely collaborate on designs through comments left on specific points in designs. By allowing Designs on issues to support this collaboration we're continuing to enhance the value of Issues as the Single Source of Truth for work inside of GitLab. At the same time we're also providing a structured way to give feedback and have a discussion around Designs.

        This is just the beginning of focusing on designer specific workflows inside of GitLab and we'd love for you to contribute to our [strategy](https://about.gitlab.com/direction/create/design_management/).

        Design Management is currently an *alpha* feature and is subject to
        change at any time without prior notice. Design Management requires [Large File Storage (LFS)](https://docs.gitlab.com/ee/workflow/lfs/manage_large_binaries_with_git_lfs.html)
        to be enabled.

    - name: "Cross-project Merge Request Dependencies"
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_dependencies.html'
      image_url: '/images/12_2/mr-dependencies.png'
      reporter: jramsay
      stage: create
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/9688'
      description: |
        Organizations that ship multiple related products often share common
        services and libraries to prevent the same problem being solved twice.
        These are often stored in their own individual projects, but this makes
        coordinating changes between services and their consumers difficult when
        a feature requires changes to multiple components.

        In GitLab 12.2, Cross-project Merge Request Dependencies allow these
        dependency relationships to be defined in GitLab, to prevent changes from
        being merged in the wrong order. It also helps increase the visibility of
        these relationships during code review, helping the reviewer understand
        the full scope of changes.

    - name: "Restrict group membership by domain"
      available_in: [premium, ultimate] 
      documentation_link: "https://docs.gitlab.com/ee/user/group/#allowed-domain-restriction-premium-only"
      image_url: "/images/12_2/manage-restrict-users-by-domain.png"
      reporter: jeremy
      stage: manage
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ee/issues/7297"
      description: | 
        For security-minded organizations, maintaining control over who has access
        to projects and groups is an important aspect of risk management. In 12.2, 
        we're adding an additional tool for administrators and group owners to
        ensure that the right people have access; you're now able to restrict
        group membership to only users who are using an email address matching
        a selected domain name.
        
        This means that YourCompany can ensure that users must be using a yourcompany.com
        email address to be allowed into the group, helping prevent owners from
        accidentally adding users outside the organization.

    - name: "Percent Rollout Strategy for Feature Flags"
      available_in: [premium, ultimate] # required
      documentation_link: "https://docs.gitlab.com/ee/user/project/operations/feature_flags.html#rollout-strategy" # required
      image_url: "/images/12_2/feature_flags_percent_rollout.png" # required
      video: "https://www.youtube.com/embed/VkcNt-ZnHq8" # example - optional - overrides image_url
      reporter: ogolowinski # required
      stage: release # required if the feature belongs to a DevOps stage.
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ee/issues/8240" # required
      description: | # supports markdown
        You can now select "Percentage Rollout" as a rollout strategy for your feature flags. Percentage Rollout allows percentages to be set individually for each environment and each flag. When Percentage rollout is configured and the flag is enabled, the feature will be shown to the configured percentage of logged-in users. This allows you to do controlled rollouts, monitoring the behavior of the target environment to ensure the results are as expected.

    - name: "User ID Rollout Strategy for Feature Flags"
      available_in: [premium, ultimate] # required
      documentation_link: "https://docs.gitlab.com/ee/user/project/operations/feature_flags.html#target-users" # required
      image_url: "/images/12_2/user_id_ff.png" # required
      reporter: ogolowinski # required
      stage: release # required if the feature belongs to a DevOps stage.
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ee/issues/11459" # required
      description: | # supports markdown
       You can now choose "User ID" as a rollout strategy for your feature flags. The User ID strategy allows you to specify a comma-separated list of User IDs and then toggle a feature flag only for the specified users. This can allow you to target testing features with specific cohorts or segments of your userbase. 
        
    - name: "Security approval in Merge Requests"
      available_in: [ultimate] # required
      documentation_link: "https://docs.gitlab.com/ee/user/application_security/#security-approvals-in-merge-requests-ultimate" # required
      image_url: "/images/12_2/vulncheck_merge_request.png" # required
      reporter: stkerr  # required
      stage: secure # required if the feature belongs to a DevOps stage.
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ee/issues/9928" # required
      description: | # supports markdown
        You can now ensure that Merge Requests which introduce new vulnerabilities are not merged unless
        specific people review and approve the change.

        This makes it easier for you and your teams to follow your compliance policies and also ensures
        that new vulnerabilities do not unintentionally get introduced into your code base without explicit approval.


    - name: "Specify variables when running a manual job"
      available_in: [core, starter, premium, ultimate] # required
      documentation_link: "https://docs.gitlab.com/ee/ci/pipelines.html#specifying-variables-when-running-manual-jobs" # required
      image_url: "/images/12_2/manual_job_variables.png" # required
      reporter: jyavorska # required
      stage: verify # required if the feature belongs to a DevOps stage.
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/24935" # required
      description: | # supports markdown
        It is now possible when starting a manual job to override/provide new variables
        that will be used by the running job. This will make it much easier to set up configurable
        custom and/or reusable jobs as part of your pipelines, as well as make it easier to
        troubleshoot when implementing pipeline jobs.

    - name: "Scoped environment variables feature moved to Core"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/ci/variables/#limiting-environment-scopes-of-environment-variables"
      image_url: "/images/12_2/scopedvars.png"
      reporter: danielgruesso
      stage: configure
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/53593"
      description: |
        Initially introduced in [GitLab Premium 9.4](https://about.gitlab.com/blog/2017/07/22/gitlab-9-4-released/#environment-specific-secret-variables),
        the ability to scope environment variables to specific environments has now moved to GitLab Core. This feature provides
        great flexibility when configuring different variables (for example, different private keys to access different environment-related infrastructure)
        and using multiple environments in the development life cycle.

        We are open-sourcing this feature in alignment with our [buyer-driven tier designation](https://about.gitlab.com/handbook/ceo/pricing/#the-likely-type-of-buyer-determines-what-features-go-in-what-tier) to encourage its use and contribution by the community.


# SECONDARY FEATURES
  secondary:
    - name: "NPM Registry now supports authentication with the GitLab Personal Access Token"
      available_in: [premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/packages/npm_registry.html#authenticating-with-an-oauth-token"
      reporter: trizzi
      stage: package
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ee/issues/9140"
      description: |
        The GitLab NPM Registry allows Javascript developers to build, publish, and version
        NPM packages using their GitLab instance. NPM requires users to authenticate with
        OAuth and prior to 12.2, the GitLab personal access token did not support OAuth. 
        Users were forced to generate their own token (outside of GitLab) in order to use the
        NPM registry, which also prevented them from leveraging two-factor authentication. 
        This was not a scalable solution for our enterprise customers.
        
        In 12.2 we are excited to announce that we now support authentication using the GitLab [personal access token](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html).
        The GitLab personal access token works seamlessly with two-factor authentication and allows users
        to choose a scope and expiration policy that works for them. Simply update your .nprmrc file
        with your personal access token and begin publishing and downloading packages to the GitLab NPM Registry.

    - name: "List users starring a project"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/profile/#user-profile"
      image_url: "/images/12_2/starrers.png"
      reporter: jeremy
      stage: manage
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/20137"
      description: | 
        [Starring](https://docs.gitlab.com/ee/api/projects.html#star-a-project) is a common way to keep 
        track of noteworthy projects. Thanks to a community contribution, it's now possible to view a list of 
        users who have starred a particular project in the UI by clicking the number of starrers on a project page. 
        This list is also available in the [Projects API](https://docs.gitlab.com/ee/api/projects.html#list-starrers-of-a-project).

        Starred projects are also available for viewing on the [user profile](https://docs.gitlab.com/ee/user/profile/#user-profile). 
        
        Thanks to [Camil Staps](https://gitlab.com/camilstaps) for the contribution!

    - name: "Maintainers can create subgroups"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/group/subgroups/index.html#creating-a-subgroup"
      image_url: "/images/12_2/manage-allow-maintainer-create-subgroup.png"
      reporter: jeremy
      stage: manage
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/51610"
      description: | 
        For large organizations prioritizing agility, subgroups are a valuable 
        tool for keeping an instance organized as it continues to scale. We're now 
        providing the option for group Owners to grant Maintainers the ability to 
        create subgroups. With this option enabled, Maintainers in a group will be
        able to move independently and quickly, without requiring intervention from
        group Owners to keep their projects organized.
        
        Thanks to [Fabio Papa](https://gitlab.com/fapapa) for the contribution!

    - name: "New push options for merge requests"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/merge_requests/#git-push-options'
      reporter: jramsay
      stage: create
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/64320'
      description: |
        Using Git push options GitLab already supports opening a merge request, and
        setting it to merge when the pipeline succeeds, all from the Git push
        command. This makes merging small changes fast and easy.

        In GitLab 12.2, GitLab has been taught new push options to:

        - Set the branch to be removed when it is merged.
        - Change the merge request's title.
        - Change the merge request's description.

    - name: Improved diff expansion
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/merge_requests/#incrementally-expand-merge-request-diffs'
      image_url: '/images/12_2/diff-expansion.png'
      reporter: jramsay
      stage: create
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/58035'
      description: |
        When viewing a diff, most unchanged lines are hidden so that it is easy
        to quickly read the changes. But sometimes more context is needed.

        In GitLab 12.2, hidden line ranges can now be revealed in full or
        incrementally. Previously hidden line ranges could only be revealed
        incrementally from the bottom of the range.

    - name: "Bulk edit issue labels at the group level"
      available_in: [premium, ultimate] # required
      documentation_link: "https://docs.gitlab.com/ee/user/group/bulk_editing/index.html" # required
      reporter: gweaver # required
      stage: plan # required if the feature belongs to a DevOps stage.
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ee/issues/7250" # required
      description: | # supports markdown
        Users can change the label for many issues at the same time in a specific project. In GitLab 12.2, we are releasing the capability to bulk edit labels for many issues at the group level, allowing for easier management of issue labels. 

    - name: "Assign groups as code owners"
      available_in: [starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/code_owners.html"
      reporter: jramsay
      stage: create
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/53182"
      description: |
        Knowing who should review your changes often isn't obvious. Assigning code owners to files makes this easy. Once assigned, you can see code owners when viewing a file and automatically add them as merge request approvers.

        In GitLab 12.2, you can now assign Groups, in addition to a GitLab username and email as code owners. Assigning a group prevents code owners falling out of sync as teams change, particularly when using LDAP to manage group membership.

    - name: Git Blame API
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/api/repository_files.html#get-file-blame-from-repository'
      reporter: jramsay
      stage: create
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/51345'
      description: |
        Understanding who last changed a line of code, and why, is helpful for
        making subsequent changes and to know who to ask for feedback. The Git
        `blame` command makes this information easy to find.

        In GitLab 12.2, the new Blame API allows this information to be retrieved
        directly from GitLab, without needing to checkout the repository. This is
        helpful for scripting and automation, based on the people who've recently
        changed the file.

        Thanks [Oleg Zubchenko](https://gitlab.com/RGBD) for your
        [contribution](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/30675).

    - name: "Design Management uploads"
      available_in: [premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/issues/design_management.html"
      image_url: "/images/12_2/design-management-uploads.png"
      video: "https://www.youtube.com/embed/CCMtCqdK_aM"
      reporter: phikai
      stage: create
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ee/issues/9492"
      description: | # supports markdown
        Designers and Developers can now easily collaborate on design assets
        inside of a GitLab issue with GitLab's Design Management uploads.
        Designs can be uploaded to a new area inside of an issue for easy tracking
        and collaboration.

    - name: "Version control for Designs"
      available_in: [premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/issues/design_management.html"
      image_url: "/images/12_2/design-management-versions.gif"
      reporter: phikai
      stage: create
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ee/issues/9491"
      description: |
        In GitLab 12.2 we're also introducing versioned designs to Design Management. Versioned
        designs provide an easy way to see changes to designs over time, making it easier to track
        changes and progress.

    - name: "Multi-select delete for the Container Registry"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/container_registry.html"
      image_url: "/images/12_2/multi_select.png"
      reporter: trizzi
      stage: package
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/24705"
      description: |

        Practicing proper container registry hygiene is important. Over time, images can accumulate and take up a significant amount of disk space. Additionally, too many tags can significantly slow down the load time of the container registry management page at **Packages > Container Registry** making it difficult to use.
        
        Previously, there have been a few options for maintaining your registry, each with their own challenges. You could use the [bulk tag delete API](https://docs.gitlab.com/ee/api/container_registry.html#delete-repository-tags-in-bulk) and [garbage collection](https://docs.gitlab.com/omnibus/maintenance/#container-registry-garbage-collection) to automate clean up, but this requires you to write and maintain a script. You could also manually delete images and tags from the management page, but this is very time-consuming as each image tag needed to be deleted one at a time.
       
        Now, we've updated and improved the GitLab UI to make manual pruning significantly faster. You can select multiple tags at a time and selecting an image will automatically select all of the associated tags. This should make it easier to maintain your registry, lowering your storage costs, and keeping page performance snappy. We're happy to release this iteration of the container registry and have more improvements on the way. Be on the lookout for future improvements such as the ability to set [policy for retention and expiration](https://gitlab.com/gitlab-org/gitlab-ce/issues/20247).  

    - name: "Manual Issue List Sorting"
      available_in: [core, starter, premium, ultimate] # required
      documentation_link: "https://docs.gitlab.com/ee/user/project/issues/sorting_issue_lists.html#manual-sorting" # required
      image_url: "/images/12_2/manual-issue-sorting.gif" # required
      reporter: gweaver # required
      stage: plan # required if the feature belongs to a DevOps stage.
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/62178" # required
      description: | # supports markdown
        It's difficult to order a large list of issues to indicate priority and/or order of implementation, which is necessary for typical use cases such as backlog grooming.
        
        As of 12.2, you can now sort an Issue List in **Manual** mode, which allows you to drag and drop Issues within the list to assign them a relative order. 

        The order is persisted and maintained across the entire instance for all Project Issue Lists and Group Issue Lists that have **Manual** mode enabled.

    - name: "Kubernetes namespace for each environment"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/clusters/#rbac-cluster-resources"
      reporter: danielgruesso
      stage: configure
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/52494"
      description: | # supports markdown
        Using the same Kubernetes cluster for multiple environments can net you some great efficiencies. For example, if dev and stage both use the same cluster, then administrative overhead goes down because you only have one cluster to manage, and infrastructure cost goes down because Kubernetes can schedule pods from both environments onto a smaller set of nodes. 
        
        Previously, GitLab didn't support this use case well, all environments in a project were deployed into the same namespace. If you wanted separate permissions for each environment (for example, if you wanted to allow engineering to deploy to dev but not stage) you needed to use a separate cluster for each.
        The GitLab Kubernetes integration now uses a dedicated namespace for each project environment, and you can finely configure permissions separately for each so you can take advantage of the efficiencies that come with using the same cluster for multiple environments. 
        
        This will allow Kubernetes users to reuse the same cluster for different environments without having to deploy all environments into 
        the same namespace. Additionally, operators are now able to finely configure permissions for each environment to allow users to deploy to some
        but not all environments.

    - name: "Uninstall Cert Manager from Kubernetes GitLab Managed Apps"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/clusters/applications.html#uninstalling-applications"
      reporter: danielgruesso
      stage: configure
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/60664"
      description: | # supports markdown
        If you installed Cert Manager to your Kubernetes cluster via the GitLab Kubernetes integration, you can now also uninstall it with a single click from the cluster page. 

    - name: "Uninstall Helm from Kubernetes GitLab Managed Apps"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/clusters/applications.html#uninstalling-applications"
      reporter: danielgruesso
      stage: configure
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/60516"
      description: | # supports markdown
        If you installed Helm to your Kubernetes cluster via the GitLab Kubernetes integration, you can now also uninstall it with a single click from the cluster page.

    - name: "Uninstall Knative from Kubernetes GitLab Managed Apps"
      available_in: [core, starter, premium, ultimate] # required
      documentation_link: "https://docs.gitlab.com/ee/user/clusters/applications.html#uninstalling-applications"
      reporter: danielgruesso
      stage: configure
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/60668"
      description: | # supports markdown

        If you installed Knative to your Kubernetes cluster via the GitLab Kubernetes integration, you can now also uninstall it with a single click from the cluster page. 

    - name: "Disable Group Or Project Email Notifications"
      available_in: [core, starter, premium, ultimate] # required
      documentation_link: "https://docs.gitlab.com/ee/user/project/settings/#disabling-email-notifications" # required
      # image_url: "" # required
      # video: "https://www.youtube.com/embed/enMumwvLAug" # example - optional - overrides image_url
      reporter: gweaver # required
      stage: plan # required if the feature belongs to a DevOps stage.
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/50020" # required
      description: | # supports markdown
        Owners can now disable email notifications at the [Group](https://docs.gitlab.com/ee/user/group/#disabling-email-notifications) or [Project](https://docs.gitlab.com/ee/user/project/settings/#disabling-email-notifications) level, regardless of individual user settings.

        If this is activated on a group level, it will cascade down to all sub-groups and projects within the parent group. 

    - name: "Filter projects by name when importing from Bitbucket Server"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/import/bitbucket_server"
      image_url: "/images/12_2/manage-bitbucket-import-filtering.png"
      reporter: jeremy
      stage: manage
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/51260"
      description: | 
        Importing your existing projects from Bitbucket Server into GitLab
        should be an easy process. However if you have thousands of
        projects, it can be challenging to be selective about which 
        Bitbucket repositories to import.
        
        In 12.2, we're taking a step to make migrations like these easier by 
        introducing a filter on the Bitbucket Server importer page, allowing
        you to specify which repositories you'd like to import by name. We're excited
        to add this filter to all of our project importers in coming releases.


    - name: "Lockfile to prevent multiple runner instances on a single host"
      available_in: [core, starter, premium, ultimate] # required
      documentation_link: "https://docs.gitlab.com/runner/" # required
      reporter: jyavorska # required
      stage: verify # required if the feature belongs to a DevOps stage.
      issue_url: "https://gitlab.com/gitlab-org/gitlab-runner/issues/4407" # required
      description: | # supports markdown
        Running multiple instances of the gitlab-runner process on a single host can cause some extremely
        confusing and hard to debug behaviors. Since this is not the intended usage, we've introduced a
        lockfile that will prevent this from accidentally occurring.

    - name: "Improved examples for automatic test splitting"
      available_in: [core, starter, premium, ultimate] # required
      documentation_link: "https://docs.gitlab.com/ee/ci/yaml/#parallel" # required
      reporter: jyavorska # required
      stage: verify # required if the feature belongs to a DevOps stage.
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/63509" # required
      description: | # supports markdown
        We already have the parallel keyword which gives control and flexibility to set up parallel
        tests (or really run any job in a parallel fashion), but this requires a lot of setup from
        a developer and sometimes the split logic just gets duplicated. There are open source solutions
        like [Test Boosters](https://github.com/renderedtext/test-boosters/) that take this a step further by also
        separating the test configuration into multiple files, handling that part of the configuration for you.
        We've updated our documentation for the `parallel` keyword to make this more obvious and
        help more teams get the most out of their pipelines.

    - name: "Improved variable masking for `@` and `:` characters"
      available_in: [core, starter, premium, ultimate] # required
      documentation_link: "https://docs.gitlab.com/ee/ci/variables/#masked-variables" # required
      reporter: jyavorska # required
      stage: verify # required if the feature belongs to a DevOps stage.
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/63043" # required
      description: | # supports markdown
        We have added support for two additional characters in variable masking,
        improving the ability for GitLab to automatically hide more, different
        kinds of secrets than it is able to today.

    - name: "Label and annotate issues using GFM in alerts from external Prometheus instances"
      available_in: [ultimate] # required
      documentation_link: "https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#external-prometheus-instances" # required
      reporter: sarahwaldner # required
      stage: monitor # required if the feature belongs to a DevOps stage.
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ee/issues/12605" # required
      description: | # supports markdown
        If you have an externally managed Prometheus instance, we just made it simpler to triage and assign incidents.
        We added a field called `gitlab_incident_markdown` which GitLab looks for on alerts and displays at the top of incidents
        in the **Summary** section. GFM ([GitLab Flavored Markdown](https://docs.gitlab.com/ee/user/markdown.html#gitlab-flavored-markdown-gfm))
        can be added to your alert configuration files in AlertManager and used to automatically assign and label issues that are opened on alerts.

    - name: "Label issues opened by Prometheus alerts with incident"
      available_in: [ultimate] # required
      documentation_link: "https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#taking-action-on-incidents-ultimate" # required
      reporter: sarahwaldner # required
      stage: monitor # required if the feature belongs to a DevOps stage.
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/63373" # required
      description: | # supports markdown
        When you have configured your project to open issues on Prometheus alerts, the `incident` label
        will now be applied automatically. This enables incident response teams to easily triage incidents
        using issue boards and eliminates manual work required to indicate issues that are incidents and
        those being used for other purposes.

    - name: "Embed Prometheus metrics in issues"
      available_in: [core, starter, premium, ultimate] # required
      documentation_link: "https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#embedding-metric-charts-within-gitlab-flavored-markdown" # required
      image_url: "/images/12_2/embed_prometheus_metrics_in_issues.png" # required
      reporter: sarahwaldner # required
      stage: monitor # required if the feature belongs to a DevOps stage.
      issue_url: "https://gitlab.com/groups/gitlab-org/-/epics/1434" # required
      description: | # supports markdown
        Metrics charts help to visualize what changed to trigger an incident. Displaying metric charts directly
        in issues allows you to get started right away when a new incident issue is generated instead of needing 
        to open dashboards to find metrics from the timeframe of the alert. While working an incident an on-call 
        engineer can use embedded charts to share knowledge and context they've gained by exploring the metrics 
        and logs. After the incident is over, the team performing a retrospective will have all of the charts in 
        one place including metrics from the initial alert and all of the forensic work done during the firefight.

        To embed metrics charts in issues, simply generate a shareable link on the chart in the metrics dashboard.
        You can specify the timeframe for the data using the dahsboard time filter and this will be saved in the URL.
        Pasting this URL in the description embeds the visualizations in the issue.

        When an incident issue is generated by an alert it can make use of a pre-configured template. Adding a 
        metric chart to the issue template will automatically embed a chart showing metrics scoped to the time of the alert.

    - name: "Read and write admin notes for a user via API"
      available_in: [starter, premium, ultimate]
      gitlab_com: false
      documentation_link: "https://docs.gitlab.com/ee/api/users.html#for-admins"
      reporter: jeremy
      stage: manage
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/53553"
      description: | 
        Writing admin notes for users can be a useful tool for administrating a
        GitLab userbase at scale. On GitLab.com, our admins typically use the `note`
        attribute to keep track of user behavior. At scale, writing these notes
        via the UI quickly becomes challenging to manage. The user API
        can now be used to read and write admin notes, making it easier than ever
        for instance admins to add reminders at the user level.

    - name: "Download CSV of Prometheus charts on the metrics dashboard"
      available_in: [core, starter, premium, ultimate] # required
      documentation_link: "https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#monitoring-cicd-environments" # required
      image_url: "/images/12_2/download_csv_from_metrics_chart.png" # required
      reporter: sarahwaldner # required
      stage: monitor # required if the feature belongs to a DevOps stage.
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/60733" # required
      description: | # supports markdown
        Many people use a screen-reader to interact with GitLab. In order for screen readers to 
        verbalize content, they need visual information, like charts, to be conveyed via text. 
        GitLab can generate chart data as a CSV file that can be downloaded and fed into a 
        screen-reader application. This can be done by accessing the drop-down menu in the upper-right
        corner of the desired chart and selecting the option to download the CSV.

    - name: "Security Dashboard as default view for groups"
      available_in: [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/profile/preferences.html#group-overview-content" # required
      image_url: "/images/12_2/group_security_dashboard_default.png" # required
      #video: "https://www.youtube.com/embed/enMumwvLAug" # example - optional - overrides image_url
      reporter: stkerr   # required
      stage: secure # required if the feature belongs to a DevOps stage.
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ee/issues/7048" # required
      description: | # supports markdown
          You can now set the group Security Dashboard as the default screen
          you will see when you view a group. Notably, this is done on a per-user
          basis, meaning everyone in the team can choose the view they are most
          interested in.
          
          This allows security teams and users primarily concerned with the
          security posture of a group to quickly determine security health
          without having to navigate through a menu to find the information.

    - name: GitLab Runner 12.2
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/runner'
      reporter: joshlambert   # required
      stage: verify # required if the feature belongs to a DevOps stage.
      description: |
        We're also releasing GitLab Runner 12.2 today! GitLab Runner is the open-source project that is used to run your CI/CD jobs and send the results back to GitLab.

        ##### Most interesting changes:

        - [Locking mechanism to prevent multiple instances of `gitlab-runner` process using the same configuration file](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1496)
        - [Configuration file template for registration command](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1263)

        List of all changes are found in GitLab Runner's [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/v12.2.0/CHANGELOG.md).

# Omnibus and performance (required)

    - name: "GitLab chart improvements"
      available_in: [core, starter, premium, ultimate]
      gitlab_com: false
      documentation_link: "https://docs.gitlab.com/charts/"
      reporter: joshlambert
      description: |
        The following improvements have been made to GitLab charts:

        - Kubernetes 1.11 is now the minimum supported version
        - `networkproxy` settings for the `registry` [can now be configured](https://docs.gitlab.com/charts/charts/registry/index.html#configuring-the-networkpolicy).
        - Load Balancer settings for `gitlab-shell` [can now be configured](https://docs.gitlab.com/charts/charts/gitlab/gitlab-shell/#loadbalancer-service).
        - Usage of Postgres prepared statements can now [be disabled](https://docs.gitlab.com/charts/charts/gitlab/migrations/#preparedstatements) for `gitlab-migrations`.

    - name: "Omnibus improvements"
      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/omnibus/"
      reporter: ljlane # required
      description: | # supports markdown
        - GitLab 12.2 includes [Mattermost 5.13](https://mattermost.com/blog/mattermost-5-13-community-plugins-devops-integrations-series-b-announcement-and-more/), an [open source Slack-alternative](https://mattermost.com/) whose newest release includes new community plugins, DevOps integrations, and more.
        - In GitLab 12.2, the default count formula for the Unicorn worker has been [adjusted](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4535) to improve handling of parallel requests in larger deployments. The formula was changed from `CPUs + 1` to `int(CPUs * 1.5 +1)`.
        - GitLab 12.2 packages are now available for [Debian Buster](https://www.debian.org/News/2019/20190706).
        - Updated `nginx` to 1.16.1, TLS v1.3 and ECDSA support is now enabled by default.
        - Updated `postgresql` to 9.6.14 and 10.9.
        - Updated `gitlab-monitor` to 4.2.0, `graphicsmagick` to 1.3.33, 
        - To improve security and availability, the Redis `KEYS` command is now disabled by default. If desired, this command and others can be [controlled or obfuscated](https://docs.gitlab.com/omnibus/settings/redis.html#renamed-commands). 
        - Added support for [Content Security Policy and nonces](https://docs.gitlab.com/omnibus/settings/configuration.html#content-security-policy) to help protect against JavaScript XSS attacks. These settings are disabled by default.

    - 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.2
      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.2 are:
        
        - [Faster repositioning on issue boards](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/30938)
        - [Labels API response no longer includes issue and merge request counts by default](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/31543)
        - [Faster searching for members of a project or group](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/30451)
        - [Load result counts on inactive search tabs asynchronously](https://gitlab.com/gitlab-org/gitlab-ee/issues/12547)
        - [Use ETag-based caching for merge request widget data](https://gitlab.com/gitlab-org/gitlab-ce/issues/61559)
        - [Reduce number of Gitaly lookups needed to render commit references in Markdown](https://gitlab.com/gitlab-org/gitlab-ce/issues/60449)
        - [Reduce number of queries needed to render list of deploy keys](https://gitlab.com/gitlab-org/gitlab-ce/issues/43080)
        - [Reduce number of Gitaly lookups needed to render submodules](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/30735)

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

# MVP
mvp:
  fullname: "Fabio Papa"
  gitlab: 'fapapa'
  description: |
    Fabio's contribution to GitLab [12.2](#maintainers-can-create-subgroups) adds a new setting which allows Maintainers to create sub-groups, in addition to Owners.
    Fabio has also contributed valuable changes to [GitLab 12.0](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/29511) and [GitLab 11.10](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/25942).

    Thanks so much to Fabio for your contributions!

# COVER IMAGE LICENCE
cover_img:
  image_url: "https://unsplash.com/photos/sYffw0LNr7s" # required
  licence: Free # which licence the image is available with - required
  licence_url: "https://unsplash.com/license" # 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: joshlambert # required
  description: | # example (supports markdown)
    - As detailed in the critical security [release blog post](https://about.gitlab.com/blog/2019/08/12/critical-security-release-gitlab-12-dot-1-dot-6-released/), existing Grafana data will be backed up, Grafana will be reset to the initial configuration, and GitLab SSO will be the only authentication mode available.
    - Rails' authenticated cookie encryption is now enabled and old sessions are automatically upgraded.
      However, session cookie downgrades are not supported. So after upgrading to 12.2, any downgrades would result to all sessions being invalidated and users are logged out.
    - Similar to GitLab 12.0 and GitLab 12.1, GitLab 12.2 will
      [automatically upgrade the PostgreSQL version to 10.9](https://docs.gitlab.com/omnibus/settings/database.html#upgrade-packaged-postgresql-server).
    - You can skip the auto-upgrade to PostreSQL 10.9 by
      creating `/etc/gitlab/disable-postgresql-upgrade`.

# DEPRECATIONS (optional)
# include as many deprecation blocks as necessary
deprecations:
  - feature_name: "Remove Kubernetes service integration page"
    due: August 22nd, 2019.
    reporter: danielgruesso
    description: |
      The Kubernetes service integration page has been removed in 12.2 in favor of the [instance-level cluster](https://gitlab.com/gitlab-org/gitlab-ce/issues/39840) functionality introduced in GitLab 11.11.
  - feature_name: "Internal visibility disabled on GitLab.com for new projects, groups, and snippets"
    due: July 30, 2019.
    documentation_link: "https://docs.gitlab.com/ee/public_access/public_access.html#internal-projects"
    reporter: jeremy
    description: | 
      The Internal visibility setting is useful for self-managed instances interested
      in making a project available for any registered user. When used on instances
      where user registration is restricted, it can become a tool to encourage [innersourcing](https://en.wikipedia.org/wiki/Inner_source).
      
      On GitLab.com, however, user registration is open and available to the
      general public. Since anyone can register and gain read access to
      resources with Internal visibility, there's little difference between 
      the Internal and Public setting.
      
      As a result, new projects, groups, and snippets may only be created as 
      Public or Private as of July 30, 2019. Existing resources set to Internal remain unchanged on GitLab.com,
      and [will be migrated to the Private visibility setting](https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/7566) 
      in the near future. Owners may consider [changing visibility settings](https://docs.gitlab.com/ee/public_access/public_access.html#how-to-change-project-visibility)
      earlier.
  - feature_name: "Ruby 2.6 required"
    due: Aug. 22, 2019
    reporter: hfyngvason
    description: |
      Beginning with GitLab 12.2, Ruby 2.6 is required to run GitLab.
      [Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/3119)
      and the [GitLab Chart](https://gitlab.com/gitlab-org/build/CNG/merge_requests/224)
      already ship with Ruby 2.6.3, but users of source installations that run Ruby 2.5
      or older will have to upgrade.
