features:
  top:
    - name: "Quickly understand your at risk projects with Project Security Grades"
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/application_security/security_dashboard/#group-security-dashboard'
      image_url: '/images/12_6/security_grade_list.png'
      reporter: matt_wilson
      stage: secure
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/11190'
      description: |
        We're excited to announce a new "security grades" feature in Group
        Security Dashboards. In addition to the existing vulnerabilities list
        and history, this new panel on the Group Security Dashboard lets you
        know which projects are most affected/at risk so you can go right to the
        projects that need the most immediate attention.

        The severity of any detected vulnerabilities on a project is used to
        create a simple A through F letter grade.  Projects are grouped by
        grade, so you can easily see which have no unresolved vulnerabilities
        (grade A) through to those with at least 1 critical (grade F).

  primary:
    - name: "Manage C/C++ packages via Conan within GitLab's Package Registry"
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/packages/conan_repository/'
      image_url: '/images/12_6/conan_repository.png'
      reporter: trizzi
      stage: package
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/8248'
      description: |
        For any development organization, having an easy and secure way to
        manage dependencies is critical. Package management tools, such as Conan
        for C/C++ developers, provide a standardized way to share and version
        control these libraries across projects.

        In GitLab 12.6, we are proud to offer Conan repositories built directly
        into GitLab. Developers can now publish their packaged libraries to
        their project’s Conan repository. Simply set the Conan remote to the
        GitLab Package Registry and start uploading, installing, and deleting
        packages today.

    - name: "Filter issues and merge requests by Release"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/search/#issues-and-merge-requests-per-project'
      image_url: '/images/12_6/filter_by_release.png'
      reporter: ogolowinski
      stage: release
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/32632'
      description: |
        Planning and managing a release can be complicated and being able to quickly
        find the related issues and merge requests makes it easier for teams to manage their work.
        In 12.6, we have added the capability to filter issues and merge requests by
        Release name. This will help find those items associated with a specific
        Release.

    - name: "Automated Release Evidence collection to support audits"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/releases/#release-evidence'
      image_url: '/images/12_6/release_evidence.png'
      reporter: jmeshell
      stage: release
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/26019'
      description: |
          When development teams release code changes in many organizations, they are required
          to document the proof that they complied with the organization's processes and policies
          in their SDLC. Typically, this can be time consuming and inefficient.  In 12.6, GitLab Releases
          now have a new **Evidence collection** entry in which you can find a snapshot of the Release's
          metadata in JSON format. This snapshot can be leveraged as a chain of custody to support review
          and compliance processes, such as audits.

    - name: "Maintain a consolidated commit history with squash-and-merge in Merge Trains"
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/'
      image_url: '/images/12_6/squash_merge.png'
      video_url: 'https://www.youtube.com/embed/pA5SfHwlq0s'
      reporter: ogolowisnki
      stage: release
      categories:
        - 'Continuous Delivery'
        - 'Merge Trains'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/13001'
      description: |
        [Squash-and-Merge](https://docs.gitlab.com/ee/user/project/merge_requests/squash_and_merge.html)
        allows you to combine all your merge request’s commits into one so you
        retain a clean history in the default branch while preserving the
        entire commit history in the merge request. In this release, we
        added squash support to Merge Trains, which allows running a build
        on the result of the merged code prior to merging, as a way to keep
        master green. The combination of these two features will ensure that
        master is always green while attaining a consolidated commit history.

    - name: "View your Security and Compliance config from a centralized interface"
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/application_security'
      image_url: '/images/12_6/configure-secure-scanners.png'
      reporter: matt_wilson
      stage: secure
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/13638'
      categories:
        - configuration
      description: |
        We are excited to announce a new ability to view the Secure scanners.
        You will see a new `Configuration` option under the `Security and
        Compliance` section on the left navigation. This UI will show you which
        security scans are available, what scans have been configured, and
        provide clear links to the relevant scanner documentation.

        **Note:** as this is the initial
        [MVC](https://about.gitlab.com/handbook/product/#the-minimally-viable-change-mvc)
        of this new feature, there currently is no advanced configuration, so
        you cannot disable or enable the scans from this screen.
        {: .note}

    - name: "Collaborate more effectively on GitLab activity directly within Circuit"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/integrations/unify_circuit.html'
      image_url: '/images/12_5/unify_circuit_configuration.gif'
      reporter: deuley
      stage: enablement
      stage_url: '/handbook/engineering/development/enablement/'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/merge_requests/19849'
      description: |
        [Circuit by Unify](https://www.circuit.com/) is a collaboration and
        communication system used by many organizations. Similar to other notification
        integrations within GitLab, you can now configure webhooks to send
        selected notifications to a Circuit conversation. Notifications link back to your
        GitLab project, eliminating the need to context switch between an email client
        in order to keep up to date with GitLab activity.

        Thanks to [Fabio Huser](https://gitlab.com/fh1ch) for [your
        contribution](https://gitlab.com/gitlab-org/gitlab/merge_requests/19849)

  secondary:

    # STAGE: MANAGE
    - name: "Entropy requirements for new user passwords"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/security/password_length_limits.html'
      gitlab_com: false
      reporter: mattgonzales
      stage: manage
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/36776'
      description: |
        Organizations need a way to secure their GitLab instances that aligns
        with their internal policies and procedures. Part of [securing
        GitLab](https://gitlab.com/groups/gitlab-org/-/epics/258) is enforcing a
        password policy. GitLab recently updated its own internal [password
        policy
        guidelines](https://about.gitlab.com/handbook/security/#gitlab-password-policy-guidelines)
        based on [NIST SP
        800-63B](https://pages.nist.gov/800-63-3/sp800-63b.html). In this
        special publication, NIST advises on leveraging password length and
        complexity, but does not recommend password rotation or even requiring
        specific complexity rules (e.g. a specific number of special
        characters).

        Using NIST's guidance, GitLab is introducing a new setting within the
        Admin Area to specify a **minimum password length** that applies only to
        new passwords. This means any new account being created or any password
        being changed will be required to meet this minimum length requirement.
        By enabling customers to define a minimum password length, GitLab
        environments can become more secure and organizations can manage this
        policy across an instance for reassurance that passwords are compliant
        with internal policies.

    - name: "Filter members list for users with direct membership"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/members/#inherited-membership'
      reporter: jeremy
      stage: manage
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/21727'
      image_url: '/images/12_6/manage-filter-group-specific-membership.png'
      description: |
        There are two ways to gain access to a private project or group: a)
        being directly added to that specific project or group or b) [inheriting
        a role from a parent
        group](https://docs.gitlab.com/ee/user/group/subgroups/index.html#membership).
        In GitLab 12.6, we're making it easier to understand the source of a
        user's membership by allowing filtering of the Members table
        specifically for direct members or inherited members.

        This is particularly useful for groups with [external
        users](https://docs.gitlab.com/ee/user/permissions.html#external-users-core-only)
        or instances using [groups for notifying teams of
        people](https://docs.gitlab.com/ee/user/group/#use-cases).

    - name: "Require rotation of personal access tokens"
      available_in: [ultimate]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/ee/user/admin_area/settings/account_and_limit_settings.html#limiting-lifetime-of-personal-access-tokens-ultimate-only'
      reporter: jeremy
      stage: manage
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/3649'
      description: |
        Security-minded organizations have historically used regular rotation of
        credentials to limit the amount of time an attacker has access to a
        system through a compromised secret. While guidelines from organizations
        like [NIST](https://pages.nist.gov/800-63-3/sp800-63b.html) no longer
        recommend periodic rotation, we're adding the ability to enforce regular
        rotation of [personal access
        tokens](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#personal-access-tokens)
        due to their inherent lack of 2FA protection, customer demand, and
        importance in certain compliance frameworks (e.g.
        [PCI](https://pciguru.wordpress.com/2019/03/11/the-new-nist-password-guidance/)).

        With this change, an instance administrator can configure a maximum
        lifetime for generated personal access tokens. Applying a limit will
        expire existing tokens, which must be regenerated and adhere to the
        newly applied expiration requirement. After a token's expiration date
        has passed, it must be regenerated.

    - name: "Simplify user management with Personal Access Token and SSH key inventory"
      available_in: [ultimate]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/ee/user/admin_area/credentials_inventory.html'
      reporter: mattgonzales
      stage: manage
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/36742'
      image_url: '/images/12_6/ssh-inventory.png'
      description: |
        As your GitLab self-managed instance grows, so too does your need for
        [compliance
        controls](https://about.gitlab.com/direction/manage/compliance-controls/).
        As more users, groups, subgroups, and projects are added, your instance becomes inherently more complex. You need visibility into who has access to your instance in an aggregate view in order to manage your instance's risks and compliance.

        To support customers in this effort, we've introduced an
        [MVC](https://about.gitlab.com/handbook/values/#minimum-viable-change-mvc)
        for an inventory of PAT and SSH credentials. This view provides
        important details to administrators, such as the owner, type, and scope
        of each credential. It will also show when a credential is set to expire
        and when it was last used.

    - name: "Protect your project data with soft deletion for projects"
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/admin_area/settings/visibility_and_access_controls.html#project-deletion-adjourned-period-premium-only'
      reporter: jeremy
      stage: manage
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/32935'
      description: |
        Currently, deleting a project in GitLab through the UI or [API](https://docs.gitlab.com/ee/api/projects.html#remove-project)
        is immediate, irreversible, and unrecoverable without restoring from a backup. This has the potential to result
        in unintentional data loss, which is a worst-case scenario for the team.

        To reduce this risk, GitLab 12.6 introduces soft deletion for projects. Instead of immediate removal of the project
        or group, the resource will be marked for deletion and removed after a configurable soft deletion time-frame. While the
        default time-frame is 7 days, instances wishing to retain immediate deletion can set this to 0.

    - name: "ConvDev Index is now DevOps Score"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/instance_statistics/dev_ops_score.html'
      reporter: jeremy
      stage: manage
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/20976'
      description: |
        As we invest further in analytics in GitLab, our features should align with commonly used 
        terms. Conversational development is a useful concept, but GitLab is built around the 
        language of DevOps. 
        
        Directly referencing this term is especially helpful for organizations looking to track 
        their adoption of DevOps best practices. We plan on 
        [iterating on this feature](https://gitlab.com/gitlab-org/gitlab/issues/20601) further, but
        a first important step is a name change to reflect where we're going.

    # STAGE: PLAN
    - name: "Disable group mentions"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/group/#disabling-group-mentions'
      reporter: gweaver
      stage: plan
      categories:
        - 'Issue Tracking'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/21301'
      image_url: '/images/12_6/disable-group-mentions.png'
      mr_url: 'https://gitlab.com/gitlab-org/gitlab/merge_requests/20184'
      description: |
        Mentioning a group with a large number of members can quickly lead to a
        high volume of unwanted notifications. To avoid this, you can now enable
        a group-level setting to prevent members from receiving notifications
        when the group is mentioned in an issue or merge request.

        Thanks [@fh1ch](https://gitlab.com/fh1ch) and Siemens!

    # STAGE: CREATE
    - name: "Preview OpenAPI specifications"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/repository/#openapi-viewer'
      image_url: '/images/12_6/openapi.png'
      reporter: jramsay
      stage: create
      categories:
        - 'source code management'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/19515'
      description: |
        The OpenAPI (previously known as Swagger) Specification is a popular
        standard for defining RESTful interfaces. However, reading the YAML
        source can be difficult. In GitLab 12.6, when viewing an `openapi.yml`
        file (or another supported filename), a rendered preview of the
        specification will be shown using the same interface as Swagger.

        Thank you [Roger Meier](https://gitlab.com/bufferoverflow) and Siemens
        for your [contribution](https://gitlab.com/gitlab-org/gitlab/merge_requests/21106)!

    - name: "Deduplicate forks of internal projects"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/administration/repository_storage_types.html#hashed-object-pools"
      reporter: jramsay
      stage: create
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/33318"
      description: |
        Forking workflows makes it easy to contribute to any project by creating
        a copy of the upstream project to work on before opening a merge request
        to merge your changes into the upstream project. For popular projects,
        the server-side storage requirements needed for thousands of copies
        accumulate quickly and increase hosting costs.

        In GitLab 12.1, we introduced fork de-duplication for public projects,
        but many organizations missed out on the benefits because they primarily
        use internal projects. In GitLab 12.6, creating a fork of public or
        internal projects creates an object pool (if one doesn’t already exist)
        and uses `objects/info/alternates` to reduce the storage requirements of
        forks.

        Thanks [Brian Kabiro](https://gitlab.com/briankabiro) for your
        [contribution](https://gitlab.com/gitlab-org/gitlab/merge_requests/19295)!

    - name: "More easily navigate between tabs within Merge Requests"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/merge_requests/"
      image_url: '/images/12_6/mr-subnav.png'
      reporter: jramsay
      stage: create
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/33813"
      description: |
        Merge Requests are where source code is reviewed, tested, and discussed,
        but they can become unwieldy. Together, merge request descriptions,
        pipelines, and security scanning results often push the navigation tabs
        far down the page making them hard to find and difficult to access.

        In GitLab 12.6, the merge request navigation is now above the
        description, making it fast and easy to jump directly to the changes.
        Additionally, the description and widgets are now displayed on the
        **Overview** tab, providing improved focus and navigation throughout the
        merge request. Please share your feedback
        [here](https://gitlab.com/gitlab-org/gitlab/issues/36125).

    - name: "Real-time merge request widget updates"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/merge_requests/"
      reporter: jramsay
      stage: create
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/31236"
      description: |
        Before clicking Merge, if you make a final tiny fix by pushing or
        applying a suggestion, the merge button is disabled until you reload the
        page. This slows down the final stages of review when applying the final
        fixes. In GitLab 12.6, the merge request widget is now updated in
        real-time so that you can merge immediately or when the pipeline
        succeeds.

    - name: "Remove fork relationship when project visibility is restricted"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/public_access/public_access.html#reducing-visibility"
      reporter: jramsay
      stage: create
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/33358"
      description: |
        Forking workflows makes it easy to contribute to any project by creating a copy of the upstream project to work on before opening a merge request to merge your changes into the upstream project.

        Previously, when the visibility of the root project in a fork network was **changed to be** restricted, the visibility of all the forks would be restricted. This could result in all forks of a public project suddenly becoming private if the root project was made private.

        In GitLab 12.6, instead of changing the visibility of all projects, the root project is simply removed from the fork network leaving all other projects unmodified. This is equivalent to the root project being deleted.


    # STAGE: VERIFY
    - name: "Remove need for client-based authorization with Visual Review Tools"
      available_in: [starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/ci/review_apps/index.html#visual-reviews-starter"
      image_url: '/images/12_6/visual-review-tools.png'
      reporter: jheimbuck_gl
      stage: verify
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/29067"
      description: |
        In GitLab 12.0, we introduced [Visual Review
        Tools](https://about.gitlab.com/blog/2019/06/22/gitlab-12-0-released/#visual-reviews)
        to allow users to provide feedback on merge requests from the Review App
        itself.

        In GitLab 12.6, we simplified usage of the tool by removing the need to
        create a personal access token to provide feedback.

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

        #### Changes include:

        - [Distribute arm64 binaries](https://gitlab.com/gitlab-org/gitlab-runner/issues/4870)
        - [Expose image to custom executor](https://gitlab.com/gitlab-org/gitlab-runner/issues/4357)
        - [Upgrade to Go 1.13](https://gitlab.com/gitlab-org/gitlab-runner/issues/4757)
        - [Fix regex for finding Virtualbox snapshot names](https://gitlab.com/gitlab-org/gitlab-runner/issues/3274)
        - [Removal of file locking](https://gitlab.com/gitlab-org/gitlab-runner/issues/5416)

        The list of all changes can be found in GitLab Runner's [CHANGELOG.](https://gitlab.com/gitlab-org/gitlab-runner/blob/12-6-stable/CHANGELOG.md)

    - name: "Inherited variables are now shown in project view"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/ci/variables/README.html#group-level-environment-variables'
      reporter: jyavorska
      stage: verify
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/24172'
      description: |
        When using a mix of project & group variables, it can be confusing to
        understand what group variables exist and how they may be related or
        conflict with project level variables. We have improved this by now
        showing the group (inherited) variables in the project variables page,
        making it easy to see what variables are coming from where.

    - name: "CI configuration outside of the repository"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/pipelines/settings.html#custom-ci-configuration-path'
      reporter: thaoyeager
      stage: verify
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/14376'
      description: |
        We have added the ability to specify the path of the `.gitlab-ci.yml` to
        an arbitrary URL, which allows you to store CI configurations in a
        repository other than the one being built. This can be very helpful for
        processing many repos the same way by pointing all of them to the same
        external `.gitlab-ci.yml` file. Efficiency is gained by having only one
        CI configuration file to update instead of maintaining individual
        configurations in each repository. Users that have a service that
        generates the configuration file dynamically would also benefit.

        This also makes it possible to protect configurations from unauthorized
        changes as the file can be hosted in a project with more fine-grained
        access control. We have updated our documentation to make it clear how
        to set this up.

    # STAGE: PACKAGE
    - name: "API endpoint to list the packages of a group"
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/api/packages.html#within-a-group'
      reporter: trizzi
      stage: package
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/10003'
      description: |
        As part of the GitLab Package Registry, we provide an
        [API](https://docs.gitlab.com/ee/api/packages.html), to allow users to
        view, download, and delete packages. However, until recently the API was
        limited to a specific project, which prevented users from understanding
        which packages exist at the group level.

        In GitLab 12.6, we are excited to announce a new API endpoint that will
        allow users to list all packages at the group level.

    - name: "The GitLab NPM registry now supports installing dependencies"
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/packages/npm_registry/#npm-dependencies-metadata'
      reporter: trizzi
      stage: package
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/11867'
      description: |
        In GitLab 12.6, we are very excited to announce that the NPM Registry
        now supports installing package dependencies. Until recently, running
        `npm install` would not work if the version was not included in the
        command. In addition, the command would not support installing the
        packages' dependencies. This was due to us not supporting the required
        NPM metadata, such as dependencies or tags.

        Moving forward, users can expect `npm install` to work as expected. Next
        we will work on [adding dependencies and tags to the Package Registry
        UI](https://gitlab.com/gitlab-org/gitlab/issues/12954).

    # STAGE: RELEASE
    - name: "Edit a release via the Releases page"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/releases/#editing-a-release'
      video: 'https://www.youtube.com/embed/brWazyNo9Gc'
      reporter: jmeshell
      stage: release
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/26016'
      description: |
        In GitLab 12.6, we are adding the capability to edit Release titles and
        notes directly from the user interface, instead of using the GitLab API.
        This provides a faster and more intuitive method to edit releases.

    - name: "Official GitLab container with AWS client installed"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/ci/cloud_deployment/index.html'
      reporter: ogolowinski
      stage: release
      categories:
        - 'Continuous Delivery'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/31167'
      description: |
        Interacting with a major cloud provider such as AWS, Azure, or GCP is a core component of many delivery pipelines. But before you can automate your cloud interactions, you need to have an environment set up with the appropriate tools. Previously this was something you had to manage on our own, but starting in 12.6, GitLab will provide an official AWS Docker image that will allow you to run `aws` commands from your CI/CD pipelines. You can access a variety of AWS services using a Docker image that is maintained and kept up-to-date by GitLab.

        Delivering an official image is also the first step in [supporting AWS deploys to EC2](https://gitlab.com/groups/gitlab-org/-/epics/2351). It’s part of our broader plan to include [native support for deploying to multiple cloud providers](https://gitlab.com/groups/gitlab-org/-/epics/1804). We hope to see community contributions for additional cloud providers using this model of pre-built images with included scripts hosted in the [official GitLab Cloud Deploy container registry](https://gitlab.com/gitlab-org/cloud-deploy/container_registry).

    - name: "Control rollout of Feature Flags based on UserID"
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/operations/feature_flags.html#user-ids'
      image_url: '/images/12_6/userid_ff.png'
      reporter: ogolowinski
      stage: release
      categories:
        - 'Feature Flags'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/34363'
      description: |
        You can now define different userID targets for your feature flags per
        environment. The value that is gained here is that with this combination
        you can target different users on production than staging (or others)
        which allows you total control on how, where and to whom your Feature
        Flag will be toggled.

    - name: "Warning for skipping Merge Trains"
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/#immediately-merge-a-merge-request-with-a-merge-train'
      image_url: '/images/12_6/merge_train_immediate_merge_confirmation.png'
      reporter: ogolowinski
      stage: release
      categories:
        - 'Continuous Delivery'
        - 'Merge Trains'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/12679'
      description: |
        When users choose **Merge Immediately** for their merge request, this
        delays all the merge requests in the Merge Train. Users were
        unintentionally doing this, unaware of the negative effect caused to the
        rest of the merge requests. Although we still allow urgent merge
        requests to skip the line, we added a warning as another layer of
        protection by explaining that this action will negatively impact others.


    # STAGE: CONFIGURE
    - name: "Delete related resources when removing Kubernetes clusters"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/clusters/add_remove_clusters.html#removing-integration'
      image_url: '/images/12_6/cluster-removal.png'
      reporter: danielgruesso
      stage: configure
      categories:
        - 'Kubernetes Management'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/26815'
      description: |
        Re-using clusters across instances, groups, or projects can be time
        consuming as operators must ensure that all related cluster resources
        (such as namespaces, roles, bindings, etc.) are removed from the cluster
        prior to linking it to a new entity. Often times, operators choose to
        destroy a cluster and create a new one to avoid manual deletion of
        resources.

        GitLab now provides the ability to remove all the related cluster
        resources upon removal, making it fast and easy to re-use clusters
        elsewhere.

    - name: "Customize Kubernetes namespace per environment"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/ci/environments.html#configuring-kubernetes-deployments'
      reporter: danielgruesso
      stage: configure
      categories:
        - 'Kubernetes Management'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/27630'
      description: |
        When you use GitLab's Kubernetes integration, it automatically creates a
        namespace to serve as a deploy target for GitLab CI/CD. This makes it
        easy to get started with Kubernetes. However, if you already have a
        cluster with an existing set of namespaces, more than likely you will
        want to designate one of those existing namespaces as a GitLab deploy
        target.

        Now with GitLab 12.6, you are able to specify a custom namespace for
        each CI environment in your `.gitlab-ci.yml` file allowing you to deploy
        to namespaces that existed before you connected your Kubernetes cluster
        to GitLab. Initially, this feature is only available for non-managed
        clusters but does support dynamic environments (e.g. for use in review
        apps).

    - name: "Automatically use customized deploy values file in Auto DevOps"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/topics/autodevops/#workers'
      reporter: danielgruesso
      stage: configure
      categories:
        - 'Auto DevOps'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/30628'
      description: |
        Auto DevOps' Auto-Deploy now allows for bulk configuration of its Helm
        chart values. By simply adding a `.gitlab/auto-deploy-values.yaml` file
        to your project, Auto DevOps will automatically detect it and use its
        values for deployment. This eliminates the need to create multiple
        `HELM_UPGRADE_EXTRA_ARGS` environment variables for your project and has
        the added benefit of version control.

    - name: "Allow clearing of cluster cache to avoid getting out of sync"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/clusters/#clearing-the-cluster-cache'
      image_url: '/images/12_6/clear_cluster_cache.png'
      reporter: danielgruesso
      stage: configure
      categories:
        - 'Kubernetes Management'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/31759'
      description: |
        We often need to carry out actions on Kubernetes clusters directly, for
        example while troubleshooting or fine tuning. Making changes to
        Kubernetes resources directly in the cluster can put GitLab out of sync
        with the cluster so it won't recreate resources because it assumes they
        already exist.

        Starting with GitLab 12.6, the Kubernetes integration will offer the
        option to clear the local cache of namespace and service accounts,
        allowing the next CI job to re-create them when necessary.

    - name: "Cloud Run for Anthos support in GKE Kubernetes clusters"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/clusters/add_remove_clusters.html#cloud-run-on-gke'
      image_url: '/images/12_4/cloud_run_v12_4.png'
      reporter: nagyv.gitlab
      stage: configure
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/27502'
      description: |
        When creating a Kubernetes cluster via GitLab's GKE integration, users
        can now optionally enable "Cloud Run on Anthos" with a single click. GKE
        will automatically provision the cluster with Knative serving, Istio,
        and HTTP load balancing, and Cloud Run will take care of keeping the
        cluster upgraded. When installed, users can continue to take advantage
        of the features offered by [GitLab
        Serverless](https://docs.gitlab.com/ee/user/project/clusters/serverless/)
        to deploy Knative services with minimal configuration.

        Note: We announced Cloud Run for Anthos support in GitLab 12.4, however
        we had to switch it off later due to compatibility issues. We've been
        working hard to ship a future-proof integration.

    - name: "Install Kubernetes applications using CI template"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/clusters/applications.html#install-using-gitlab-ci-alpha'
      image_url: '/images/12_6/cluster_apps_template.png'
      reporter: danielgruesso
      stage: configure
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/7983'
      description: |
        Installing Kubernetes applications [using GitLab CI](https://docs.gitlab.com/ee/user/clusters/applications.html#install-using-gitlab-ci-alpha)
        provides a great way to customize Helm charts prior to installation.
        In order to make it easier to get started, we have added a
        [CI template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Managed-Cluster-Applications.gitlab-ci.yml)
        with all the currently supported applications. In addition to this template, we
        have created an [example cluster-management project](https://gitlab.com/gitlab-org/cluster-integration/example-cluster-applications)
        containing all the necessary items required to get started. Simply import and mirror
        this project to get all the latest supported apps.

    - name: "Knative 0.9 support"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/clusters/serverless/'
      reporter: nagyv.gitlab
      stage: configure
      categories:
        - Serverless
      issue_url: 'https://gitlab.com/gitlab-org/gitlabktl/issues/55'
      description: |
        Starting with GitLab 12.6, when you install Knative as a GitLab Managed App, version 0.9 will be installed. This is a major upgrade in the life of Knative. [Knative Serving](https://knative.dev/docs/serving/)
        has received its final v1 API endpoints and is considered to be production ready, but the `beta` and `alpha`
        endpoints are still available. Given the stable API, this upgrade provides some level of forward-compatibility too.

    # STAGE: MONITOR
    - name: "Improved integration between Error Tracking and Issue management"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/operations/error_tracking.html#error-details'
      reporter: sarahwaldner
      stage: monitor
      categories:
        - 'Error Tracking'
      issue_url: 'https://gitlab.com/groups/gitlab-org/-/epics/2210'
      description: |
        Triaging errors can be a manual and tedious process often completed by
        multiple individuals on your team. One team member may determine the
        Error is critical and go to create issues to fix the error. Starting in
        GitLab 12.6, Errors provide a link to open issues directly within the Error detail page, eliminating any confusion about
        whether an issue needs to be created.

        If an issue doesn't exist, you can now quickly create a GitLab issue from an generated Error when viewing that Error's detail page.

    - name: 'Show recent searches when filtering errors'
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/operations/error_tracking.html#error-tracking-list'
      image_url: '/images/12_6/error-recent-search.png'
      reporter: sarahwaldner
      stage: monitor
      categories:
        - 'Error Tracking'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/34067'
      description: |
        You've been there. You are troubleshooting an error you found in your
        application and have to frequently jump back and forth between searches
        through your error list. Starting in GitLab 12.6, you'll be able to
        quickly select recent searches when filtering errors.

    - name: 'Add Sentry as a GitLab Managed App'
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/clusters/applications.html#install-sentry-using-gitlab-ci'
      reporter: sarahwaldner
      stage: monitor
      categories:
        - 'Error Tracking'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/26513'
      description: |
        If you're a user of GitLab's Error Tracking features, you value the
        ability to integrate with Sentry, the most popular open-source error
        tracking tool. Starting in GitLab 12.6, if you are unable to utilize a
        Sentry project on Sentry.io, you can deploy Sentry directly to a
        Kubernetes Cluster attached to your project or group. This will make it
        much quicker to get started with integrated error tracking in GitLab.

    - name: 'Sort error list by first seen, last seen and frequency'
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/operations/error_tracking.html#error-tracking-list'
      image_url: '/images/12_6/error-sorting.png'
      reporter: sarahwaldner
      stage: monitor
      categories:
        - 'Error Tracking'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/34068'
      description: |
        Errors are often plentiful, noisy, and challenging to dig through to
        find the important ones which are impacting your users. Starting in
        GitLab 12.6, as you view a list of Sentry errors in GitLab, you'll be
        able to sort those errors based on frequency and when an error was last
        and first seen.

    - name: "Access Pod Logs Directly from the Operations Tab"
      available_in: [ultimate]
      image_url: '/images/12_6/Pod_Log_Tab.png'
      documentation_link: 'https://docs.gitlab.com/ee/user/project/clusters/kubernetes_pod_logs.html'
      reporter: dhershkovitch
      stage: monitor
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/24088'
      epic_url: 'https://gitlab.com/groups/gitlab-org/-/epics/2114'
      description: |
        Previously, there wasn't an easy way to navigate directly to your pods'
        logs view. In order to get to them you had to navigate to your project's **Environments** tab
        underneath **Operations**, select the desired environment, and click the
        relevant pod. Now, with GitLab 12.6, viewing Pod Logs is easier than
        ever! Simply click on the **Pod Logs** tab underneath **Operations**.

    # STAGE: SECURE
    - name: "Support for PHP added in License Compliance"
      available_in: [ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/application_security/license_compliance/#supported-languages-and-package-managers"
      reporter: NicoleSchwartz
      stage: secure
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/7739"
      description: |
        If you are using PHP in your project, you can now use our [License
        Compliance](/direction/secure/composition-analysis/license-compliance/)
        feature. Please note this is at the `experimental` support level. We
        added support for PHP, specifically focusing on composer-based projects
        (using `composer.lock`).

    - name: "Dependency Scanning improvement for Python projects"
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#available-variables'
      reporter: NicoleSchwartz
      stage: secure
      categories:
        - 'Dependency Scanning'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/8524'
      description: |
        If your Python dependencies are stored in a file other than the regular
        `requirements.txt`, with GitLab 12.6, you can now set the requirements
        file with the `PIP_REQUIREMENTS_FILE` variable.

    - name: "Dependency Scanning for Java Gradle projects"
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#supported-languages-and-package-managers'
      reporter: NicoleSchwartz
      stage: secure
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/13075'
      description: |
        For users with [Java Gradle](https://gradle.org/) projects, you can now
        leverage our [Dependency
        Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/)
        features.

    - name: "SAST Support for React framework (JavaScript)"
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks'
      reporter: NicoleSchwartz
      stage: secure
      categories:
        - 'SAST'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/11069'
      description: |
        If you have projects written using the React framework for JavaScript,
        you can now use our
        [SAST](https://docs.gitlab.com/ee/user/application_security/sast/)
        scanners to find any security issues.

    - name: "SAST for Kubernetes manifests"
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks'
      reporter: NicoleSchwartz
      stage: secure
      categories:
        - 'SAST'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/12752'
      description: |
        Kubernetes manifests can now be checked for sensitive data like secrets and privileges, by using [`kubesec`](https://kubesec.io/).

    - name: "Dependency scanning for Scala projects using the sbt package manager"
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#supported-languages-and-package-managers'
      reporter: NicoleSchwartz
      stage: secure
      categories:
        - 'Dependency Scanning'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/12390'
      description: |
        With GitLab 12.6, we have added support for Scala with the [sbt package manager](https://www.scala-sbt.org/)
        in Dependency Scanning. You are now able to scan your Scala projects for potential vulnerabilities.

    - name: "SAST compatible with private dependencies"
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/application_security/sast/#using-environment-variables-to-pass-credentials-for-private-repositories'
      reporter: NicoleSchwartz
      stage: secure
      categories:
        - 'SAST'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/11137'
      description: |
        Projects that have dependencies that are hosted in a private repository
        now have a way of propagating authentication credentials for the private
        repository into the SAST container to have them used by the analyzing
        command.

    # STAGE: ENABLEMENT
    - name: "Group Webhooks are now editable"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/group/#advanced-settings'
      reporter: deuley
      stage: enablement
      stage_url: '/handbook/engineering/development/enablement/'
      categories:
        - 'integrations'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/10433'
      mr_url: 'https://gitlab.com/gitlab-org/gitlab/merge_requests/20898'
      description: |
        Group Webhooks are now editable! Previously, it was only possible to
        create and delete them, so making a change to a webhook required you to
        delete the webhook and start over. This addition adds the ability to
        edit these in the UI, saving you time and effort when setting up your
        webhooks.

    - name: "Webhook logs now available for CI integrations"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/integrations/project_services.html'
      image_url: '/images/12_6/webhook_logs.png'
      reporter: deuley
      stage: enablement
      stage_url: '/handbook/engineering/development/enablement/'
      categories:
        - 'integrations'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/34285'
      mr_url: 'https://gitlab.com/gitlab-org/gitlab/merge_requests/20976'
      description: |
        To assist users in troubleshooting CI integrations, we've added a log of
        recent events to the integration configuration pages. This log is
        available on the integrations settings pages for Jenkins, Packagist,
        Team City, DroneCI, Buildkite, and Bamboo. This new section lists the
        events that have triggered this integration in the last two days.

        This is particularly valuable when you are trying to troubleshoot a
        failing integration, as previously there was no place in the UI directly where these
        errors were displayed. Now, you'll have easy access to understand what
        has failed (or is currently working!) and why.

    - name: "Jira issue links are now optional"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/integrations/jira.html#disabling-comments-on-jira-issues'
      reporter: deuley
      stage: enablement
      stage_url: '/handbook/engineering/development/enablement/'
      categories:
        - 'integrations'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/20321'
      mr_url: 'https://gitlab.com/gitlab-org/gitlab/merge_requests/19004'
      description: |
        When a user has GitLab [integrated with Jira](https://docs.gitlab.com/ee/user/project/integrations/jira.html), comments are posted in Jira
        when activity happens in GitLab. This addition allows a user to [disable
        those comments](https://docs.gitlab.com/ee/user/project/integrations/jira.html#disabling-comments-on-jira-issues) from the configuration page on a per-integration basis.

        This is valuable for many users who don't want to see the comments, but
        still want to automatically link their Jira issues to their GitLab
        projects. Additionally, some users have noted use cases where there are
        Jira users who _should not have visibility_ of activity on the
        repository for confidentiality reasons. Having more fine-grained control
        over what content is posted to these comments is valuable for both of
        these cases.

    - name: "Reduce GitLab memory usage with Puma (Experimental)"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/omnibus/settings/puma.html'
      reporter: joshlambert
      stage: enablement
      stage_url: '/handbook/engineering/development/enablement/'
      categories:
        - 'memory'
      issue_url: 'https://gitlab.com/groups/gitlab-org/-/epics/954'
      description: |
        In order to reduce the memory requirements of GitLab, we are migrating to
        [Puma](https://puma.io) from [Unicorn](https://bogomips.org/unicorn/).
        Puma supports multi-threading, which can reduce the memory footprint of
        GitLab by about 30%.

        Puma support is currently experimental, while we work to
        [enable Puma by default](https://gitlab.com/gitlab-org/gitlab/issues/31765)
        in 13.0. You can try it on a [test system today](https://docs.gitlab.com/omnibus/settings/puma.html),
        and report any issues [here](https://gitlab.com/gitlab-org/gitlab/issues/new?issue).

    - 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.6
      reporter: multiple
      description: |
        We continue to improve the performance of GitLab with every release
        for GitLab instances of every size.

        Some of the improvements in GitLab 12.6 are:

        - [Enable HTTP caching for merge request comments polling](https://gitlab.com/gitlab-org/gitlab/merge_requests/20440)
        - [Reduce SQL queries when loading user avatars](https://gitlab.com/gitlab-org/gitlab/merge_requests/20847)
        - [Improve performance of SQL used in determining which Ci::JobArtifact records to sync to Geo secondary nodes](https://gitlab.com/gitlab-org/gitlab/issues/10286)
        - [Remove an N+1 call rendering projects search results and fix false positive tests](https://gitlab.com/gitlab-org/gitlab/merge_requests/21626)
        - [Improve issues search performance on GraphQL](https://gitlab.com/gitlab-org/gitlab/merge_requests/20784)
        - [Preload group ancestor to avoid N+1](https://gitlab.com/gitlab-org/gitlab/merge_requests/20977)
        - [Improve .groups_user_can_read_epics performance](https://gitlab.com/gitlab-org/gitlab/merge_requests/20833)
        - [Remove stickyMonitor from diff_file_head.vue](https://gitlab.com/gitlab-org/gitlab/merge_requests/21076)

    - name: "Omnibus improvements"
      available_in: [core, starter, premium, ultimate]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/omnibus/'
      reporter: ljlane
      description: |
        - GitLab 12.6 includes Mattermost 5.17.1, an [open source
          Slack-alternative](https://mattermost.com/). This version of
          Mattermost is focused on [quality
          improvements](https://docs.mattermost.com/administration/changelog.html#release-v5-17-1-quality-release).

mvp:
  fullname: "Fabio Huser"
  gitlab: fh1ch
  description: |
    Fabio contributed several impactful merge requests in 12.6 such as [exposing
    the option to disable group
    mentions](https://gitlab.com/gitlab-org/gitlab/merge_requests/20184),
    [surfacing the coverage delta on
    MRs](https://gitlab.com/gitlab-org/gitlab/merge_requests/20676), [adding
    pagination to Project
    Releases](https://gitlab.com/gitlab-org/gitlab/merge_requests/19912), and
    [building in support for Unify Circuit as a project
    service](https://gitlab.com/gitlab-org/gitlab/merge_requests/19849).

    Thanks Fabio and the rest of the crew from Siemens!

cover_img:
  image_url: "https://unsplash.com/photos/5RgShZblKAQ" # required
  licence: Unsplash # which licence the image is available with - required
  licence_url: "https://unsplash.com/license" # required

cta:
  - title: "Join us for an upcoming event" # default
    link: '/events/'
  - title: "Join us at GitLab Commit"
    link: '/events/commit/'
  - title: "Release survey"
    link: 'https://docs.google.com/forms/d/e/1FAIpQLSdWA8nKZ7eRMDOk3HCJTLRvaSRTY22GGyyE-8cvfCwIuy3Iyg/viewform'

upgrade:
  reporter: ogolowinski
  description: |
    As part of our architecture updates for GitLab pages, Pages will be using an
    API instead of using disk-database access. This has already been done on
    GitLab.com.

    To help with the larger migrations, we have introduced background migrations
    (Sidekiq jobs that will run asynchronously) for this release. For
    GitLab.com, these migrations took around 36 hours to complete, and no side
    effects were expected nor introduced.

    To find the approximate time it will take to complete these migrations on
    your instance, run the following command from a Rails console:
    `(Project.count.to_f / 300_000).ceil`. To check the status of the background
    migrations, run: `Sidekiq::Queue.new`
    `('background_migration').size`.

    For more information see the [issue for Pages virtual host configuration
    API](https://gitlab.com/gitlab-org/gitlab/issues/28781).

deprecations:
  - feature_name: "Kubernetes 1.11 no longer supported"
    due: Dec 22, 2019
    reporter: ljlane
    issue_url: 'https://gitlab.com/gitlab-org/charts/gitlab/issues/1583'
    documentation_link: 'https://docs.gitlab.com/charts/installation/'
    description: |
      When deploying GitLab in Kubernetes, the minimum supported version of
      Kubernetes is now 1.12. Kubernetes 1.11 is [no longer maintained
      upstream](https://kubernetes.io/docs/setup/release/version-skew-policy/#supported-versions),
      and has recently been dropped by popular container management services
      such as GKE and EKS. GitLab uses Kubernetes 1.13 by default.

  - feature_name: "Deprecated variables and argument for manual configurations of `.gitlab-ci.yml` when using Secure features"
    due: Dec. 22, 2019
    reporter: NicoleSchwartz
    description: |
      As previously announced in [Release Post
      12.0](/blog/2019/06/22/gitlab-12-0-released/#deprecated-variables-and-argument-for-manual-configurations-of-%60.gitlab-ci.yml%60-when-using-secure-features),
      if you have manually configured `.gitlab-ci.yml`:

      - The command line argument `--auth-first-page` was removed in [issue 7182](https://gitlab.com/gitlab-org/gitlab/issues/7182) and is no longer supported and you need to remove it.
      - The `DEP_SCAN_DISABLE_REMOTE_CHECKS` flag variable for Dependency Scanning was removed in [issue 9953](https://gitlab.com/gitlab-org/gitlab/issues/9953) and is no longer supported and you need to remove it.
      - The `sast_container` value in the `GITLAB_FEATURES` pre-defined environment variable was removed in [issue 8217](https://gitlab.com/gitlab-org/gitlab/issues/8217) and is no longer supported and you need to change it to `container_scanning` instead.
      - You also need to verify that you are using the [new report syntax](https://docs.gitlab.com/ee/ci/yaml/README.html#artifactsreports), since all Security scanning features are dependent on the reports being available in the expected location. If you do not update to the new report syntax, they will stop working.

      If you use the [vendored templates](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#configuration) instead of manually defining the jobs, you don't need to do anything.

  - feature_name: "All find-sec-bugs analyzers have been replaced by spotbugs"
    due: Dec. 22, 2019
    reporter: NicoleSchwartz
    description: |
      We've deprecated our four find-sec-bugs analyzers:
      [find-sec-bugs](https://gitlab.com/gitlab-org/security-products/analyzers/find-sec-bugs),
      [find-sec-bugs-groovy](https://gitlab.com/gitlab-org/security-products/analyzers/find-sec-bugs-groovy),
      [find-sec-bugs-sbt](https://gitlab.com/gitlab-org/security-products/analyzers/find-sec-bugs-sbt),
      [find-sec-bugs-gradle](https://gitlab.com/gitlab-org/security-products/analyzers/find-sec-bugs-gradle).
      You should be using our
      [spotbugs](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs)
      analyzer in place of these.

  - feature_name: "Elasticsearch 5.6 no longer supported"
    due: January 22, 2020
    reporter: phikai
    description: |
      As we continue to improve and enhance our integration with Elasticsearch, support for
      Elasticsearch 5.6.x will end with the release of GitLab 12.7. Elasticsearch 5.6 reached its
      [end of life](https://www.elastic.co/support/eol) with the release of Elasticsearch 7.x. Updated
      [version requirements](https://docs.gitlab.com/ee/integration/elasticsearch.html#version-requirements)
      for GitLab 12.7 will include support for only Elasticsearch 6.x.

      At this time there is no timeline for support of Elasticsearch 7.x with GitLab; you can follow
      [this issue](https://gitlab.com/gitlab-org/gitlab/issues/11197) for updates. GitLab recommends
      self-managed customers upgrade to ElasticSearch 6.x.

  - feature_name: "Backported os.Expand"
    due: May 22, 2020
    reporter: deastman
    description: |
      In GitLab Runner 13.0 we will remove the backported `os.Expand()` from Go
      v1.10.8. This backport was needed to include a change in behavior
      introduced in Go v1.11. Additional details can be found in [issue #4915](https://gitlab.com/gitlab-org/gitlab-runner/issues/4915).

  - feature_name: "Manual parsing of DockerService"
    due: May 22, 2020
    reporter: deastman
    description: |
      In GitLab Runner 13.0 we will revert to using the default TOML parser.
      Additional details can be found in [issue #4922](https://gitlab.com/gitlab-org/gitlab-runner/issues/4922).

  - feature_name: "Windows Batch `cmd` for the shell executor"
    due: May 22, 2020
    reporter: deastman
    description: |
      In GitLab 11.11, we deprecated the use of Windows Batch executor for the
      GitLab Runner. Support for Windows Batch will be removed in GitLab 13.0.
      Additional details can be found in [issue #6099](https://gitlab.com/gitlab-org/gitlab-runner/issues/6099)

  - feature_name: "Deprecate Ruby string interpolation on Prometheus queries"
    due: May 22, 2020
    reporter: dhershkovitch
    description: |
      We plan to remove the Ruby string interpolation (curly braces with a
      leading percent) in the next major version (GitLab 13.0) and replace it
      with [liquid template
      support](https://gitlab.com/gitlab-org/gitlab/issues/37990). If you are
      using the following format `'string_%{variable}_string'` on your
      Prometheus queries to pass parameters, you'll need to replace it with
      `'string_{{variable}}_string'`.

  - feature_name: "Gitlab 13.0 will drop support for InfluxDB self monitoring
  metrics"
    due: May 22, 2020
    reporter: dhershkovitch
    description: |
      We plan to remove the GitLab self monitoring metrics collected by
      InfluxDB in the next major version (GitLab 13.0).
      [Prometheus](https://docs.gitlab.com/ee/administration/monitoring/prometheus/)
      is our official self monitoring tool for GitLab. It is installed by
      default on every GitLab instance and is collecting the same metrics as
      InfluxDB.

  - feature_name: "Planned removal of PostgreSQL 9.6 and 10.x in GitLab 13.0"
    due: May 22, 2020
    reporter: ljlane
    description: |
      To take advantage of improved performance and functionality in PostgreSQL 11 such as
      [partitioning](https://www.2ndquadrant.com/en/blog/partitioning-evolution-postgresql-11/), we
      plan to require PostgreSQL versions [11](https://www.postgresql.org/about/news/1894/) and
      [12](https://www.postgresql.org/about/news/1976/) in GitLab 13.x. To accomplish this, we will
      be introducing support for PostgreSQL 11 in an upcoming release of GitLab 12.x while maintaining support for 9.6 and 10.x.
      With the arrival of GitLab 13.0, PostgreSQL 11 will be required.

      By minimally requiring PostgreSQL 11, we are able to leverage the new features introduced, without
      the overhead of maintaining multiple code paths. Going forward, we will be maintaining a yearly
      cadence of PostgreSQL upgrades, with support for the second and third most recent versions as soon as
      we are able to add them. We welcome your feedback on the proposed removals. Please comment in the
      [Move to PG 11 and 12](https://gitlab.com/groups/gitlab-org/-/epics/2184) epic.

  - feature_name: "Move Geo settings to Admin Area > Geo > Settings"
    due: May 22, 2020
    reporter: fzimmer
    description: |
      Geo settings [have
      moved](https://gitlab.com/gitlab-org/gitlab/issues/31938) to **Admin Area
      > Geo > Settings**. The old location (**Admin Area > Settings > Geo**)
      will remain available with automatic redirection until GitLab 13.0.
