features:
# TOP FEATURE
  top:
    - name: "Merge Request Reviews"
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/discussions/index.html'
      image_url: '/images/11_4/batch-comments.png'
      reporter: victorwu
      team: plan
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/1984'
      description: |
        Code review in merge requests is a powerful feature in GitLab. Team members
        have conversations linked to specific lines of code in a diff, and can even
        resolve them. However, the process can get unwieldy in merge requests with
        large diffs. Often, a reviewer may need to leave upwards of 10 or more comments
        in a single sitting. And the 9th or 10th comment may actually render earlier
        comments unnecessary. The end result is that the merge request author
        gets a slew of notifications and has to sort them out one by one.

        With this release, we are introducing Merge Request Reviews. This will
        allow a reviewer to draft as many code comments in a merge requests as they
        wish, make sure they are all consistent, and then submit them all
        as a single action. Since the drafts are saved to GitLab, a reviewer can
        even spread their work over many sessions, say starting a review on their
        desktop at work during the day, and then wrapping it up at home on their
        tablet device later in the evening. Once the draft comments are submitted,
        they appear as normal individual comments. This allows individual team members
        the flexibility to do code review however they want, but still being compatible
        with the entire team.

        In future iterations, we will improve the feature to provide a
        [preview](https://gitlab.com/gitlab-org/gitlab-ee/issues/4327)
        before the batch submit action, and also combine all those notifications
        that those comments currently generate, into
        [one batched notification](https://gitlab.com/gitlab-org/gitlab-ee/issues/4326).

# PRIMARY FEATURES
  primary:
    - name: "Create and toggle feature flags for your applications (alpha)"
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/operations/feature_flags.html'
      image_url: '/images/11_4/feature_flags.png'
      reporter: jyavorska
      team: release
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/6220'
      description: |
        This feature gives you the ability to create and manage feature flags for
        your software directly in the product. Simply create a new feature
        flag, validate it using the simple API instructions in your software,
        and you have the ability to control the behavior of your software
        in the field via the feature flag within GitLab itself.

        Feature Flags offer a feature toggle system for your application.
        They enable teams to achieve Continuous Delivery by deploying new
        features to production in smaller batches for controlled testing,
        separating feature delivery from customer launch. This helps reduce
        risk, and allows you to easily manage which features to enable.

        Note that this is an alpha feature being introduced for the first time,
        so while we encourage you to check out the feature and provide feedback,
        we want you to be aware that the implementation could change in subsequent
        releases.

    - name: "File tree for browsing merge request diff"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/merge_requests/index.html#merge-request-diff-file-navigation'
      image_url: '/images/11_4/file-tree.png'
      reporter: jramsay
      team: create
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/14249'
      description: |
        Code review is an essential practice of every successful project, but
        knowing what has changed can be hard to determine from a flat list of
        diffs. GitLab now includes a searchable file tree of changes to make it
        easy to see which files have changed and jump between them.

        The file tree summarizes the structure and size of the change, similar
        to `diff-stats`, providing an overview of the change and improving
        navigation between diffs. Search allows reviewers to limit their code
        review to a subset of files by path or filetype, simplifying reviews by
        specialists focussed on only a subset of the merge request.

        Previously the list of changed files was available through a searchable
        drop down, that was best suited to jumping to a specific file.

    - name: "Suggest Code Owners as merge request approvers"
      available_in: [starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_approvals.html#codeowners-file'
      image_url: '/images/11_4/suggest-approvers.png'
      reporter: jramsay
      team: create
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/5382'
      description: |
        Knowing who is the best person to review your changes isn't always
        obvious. Code owners are now shown as suggested approvers when creating
        or editing a merge request to make assigning the right person easy.

        Support for defining code owners was introduced in
        [GitLab 11.3](/blog/2018/09/22/gitlab-11-3-released/#code-owners). In
        upcoming releases, code owners will be further integrated into the
        merge request workflow with
        [automatic assignment](https://gitlab.com/gitlab-org/gitlab-ee/issues/1012)
        and
        [required approvals](https://gitlab.com/gitlab-org/gitlab-ee/issues/4418).

    - name: "New user profile page overview"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/profile/#user-profile'
      image_url: '/images/11_4/user-profile-redesign.png'
      reporter: akaemmerle
      team: manage
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/49801'
      description: |
        No matter how engaged you are on GitLab, your activity is a relevant
        source of information and engagement indicator, displayed right at your
        personal profile page. Your personal profile should give a simple insight
        into what you are interested in and working on.

        With this release, we introduce a redesigned profile page overview, showing
        your activity via the familiar but shortened contribution graph with your
        latest activities and your most relevant personal GitLab projects.

    - name: "Set and show your status message within the user menu"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/profile/#current-status'
      image_url: '/images/11_4/user-menu-status.png'
      image_noshadow: true
      reporter: akaemmerle
      team: manage
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/49075'
      description: |
        With [GitLab 11.2](/blog/2018/08/22/gitlab-11-2-released/#personal-status-messages)
        we introduced personal status messages for the first time, allowing you to
        share your current availability, mood, or simply your favorite animal.

        With this release, we make setting your status even more simple and
        frictionless. A new "Set status" item in your user menu provides a fresh
        modal that allows you to set and clear your status right within context.
        In addition, your set status is also shown in your user menu, on top of
        your full name and user name, including set Emoji and message.

    - name: "Move ability to use includes in <code>.gitlab-ci.yml</code> from Starter to Core"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/ci/yaml/#include'
      image_url: '/images/11_4/verify-includes.png'
      reporter: jyavorska
      team: verify
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/42861'
      description: |
        We are very happy to announce in this release that the usage of
        includes within the `.gitlab-ci.yml` is now available in Core. This
        will help ensure templates and other shared resources are always
        compatible between free and non-free users, and also unlocks the
        ability for everyone to do best-practice development using reusable
        snippets in your CI/CD pipelines.

    - name: "Run jobs <code>only</code>/<code>except</code> for modifications on a path or file"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/ci/yaml/#only-and-except-simplified'
      image_url: '/images/11_4/verify-onlyexceptchanges.png'
      reporter: jyavorska
      team: verify
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/19232'
      description: |
        A popularly requested feature, we're proud to now offer the
        ability within the `.gitlab-ci.yml` to use `only`/`except` rules for jobs
        based on when modifications occur to a specific file or path (glob).

        This will allow more control for users whose repositories contain different
        kinds of assets or builds, ensuring only the appropriate steps are
        executed for the kinds of changes that were committed, speeding up
        overall pipeline execution.

    - name: "Add timed incremental rollouts to Auto DevOps"
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/topics/autodevops/#timed-incremental-rollout-to-production'
      image_url: '/images/11_4/timed_incremental_rollouts.png'
      reporter: jyavorska
      team: release
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/7545'
      description: |
        You've had the ability within Auto DevOps to setup incremental
        rollouts for a while now, and with this release, we are adding
        an option to also set up _timed_ incremental rollouts where
        the rollout will automatically continue on a timed cadence
        unless there is some error.

    - name: "Support Kubernetes RBAC for GitLab managed apps"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/clusters/#role-based-access-control-rbac'
      image_url: '/images/11_4/k8s-rbac.png'
      reporter: danielgruesso
      team: configure
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/29398'
      description: |
        Security is paramount when setting up your infrastructure for the first time or connecting to
        existing one. Role-based access control (RBAC) was made generally available as part of Kubernetes'
        1.8 release, providing more granular controls to regulate access to Kubernetes resources.

        Our Kubernetes integration will now offer the capability to either create an RBAC-enabled
        cluster on GKE or to connect with an existing cluster that is RBAC-enabled, providing increased
        security for your infrastructure.

    - name: "Auto DevOps support for RBAC"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/topics/autodevops/'
      image_url: '/images/11_4/autodevops-rbac.png'
      reporter: danielgruesso
      team: configure
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/44597'
      description: |
        Auto DevOps now supports interacting with and deploying applications to RBAC-enabled Kubernetes clusters.

        Role-based access control (RBAC) is an important tool that allows operators to ensure the reliability,
        security, and efficiency of their Kubernetes cluster. Using Auto DevOps in conjunction with an RBAC-enabled
        cluster ensures your applications take advantage of the increased infrastructure security.

    - name: "Support PostgreSQL DB migration and initialization for Auto DevOps"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/topics/autodevops/#auto-deploy'
      image_url: '/images/11_4/db-migrations.png'
      reporter: danielgruesso
      team: configure
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/48004'
      description: |
        Using Auto DevOps to automatically detect, build, test, deploy, and monitor your application
        just got more powerful. Starting in 11.4, Auto DevOps now provides the ability to initialize or
        migrate PostgreSQL databases in your project.

        Simply define a project variable to initialize or migrate your PostgreSQL database, and Auto DevOps
        will do the rest.

# SECONDARY FEATURES
  secondary:
    - name: "List of subscribed labels"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/labels.html#searching-for-project-labels'
      image_url: '/images/11_4/subscribed-labels.png'
      reporter: victorwu
      team: plan
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/50835'
      description: |
        Labels in GitLab are very powerful since they can be applied to issues,
        merge requests, and epics. As you use more labels, it can be difficult to
        maintain them.

        In a recent previous release, we added the ability to search by labels on
        the project labels list page. With this release, you can now search by labels,
        sort by name/created at/updated at, and even see a list of labels you have
        subscribed to. This is available both in group and project labels list pages.

    - name: "Filter by WIP merge requests"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/merge_requests/work_in_progress_merge_requests.html'
      image_url: '/images/11_4/wip-filter.png'
      reporter: victorwu
      team: plan
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/13650'
      description: |
        Merge requests are a core part of GitLab, allowing team members to collaborate
        on code transparently. In particular, we encourage teams to share their
        work early, and use the WIP (work in progress) feature to indicate that
        a merge request is still undergoing active work and should not be merged
        yet.

        With this release, we're making it easier for users to differentiate
        between WIP and non-WIP merge requests by having a dedicated filter in
        both group-level and project-level merge requests lists. This allows users
        to quickly focus in on merge requests that are still in their early stages
        of work, versus those that are toward the final stages of review before
        merge.

    - name: "Highlight <code>@mentions</code> for yourself distinctly"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/issues/issues_functionalities.html#13-mentions'
      image_url: '/images/11_4/highlight-yourself-distinct.png'
      reporter: victorwu
      team: plan
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/49036'
      description: |
        When collaborating in a long discussion in an issue or merge request, often
        many users are involved, making it difficult to quickly at a glance, see
        comments that are directed at you.

        With this release, `@mentions` for yourself (i.e. the current user), are highlighted
        in a different color, allowing you to easily see which comments involve you,
        helping you focus on them quickly.

    - name: "Click to insert Markdown table and link"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/markdown.html'
      image_url: '/images/11_4/link-table-markdown.png'
      reporter: victorwu
      team: plan
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/29788'
      description: |
        GitLab supports GitLab Flavored Markdown (GFM) in most places throughout
        GitLab where you enter text, providing the power of rich formatting with
        a simple syntax. In particular, you can create tables in GFM. Previously,
        this was painful to use, especially for large tables, since you had to type
        a lot of characters or paste in a previous table just to format it the way
        you want. Similarly, GFM also supports URL links. But sometimes you may
        forget the particular syntax.

        With this release, you can now click on the table button in the GFM editor,
        and this will automatically insert a table for you. You can then easily
        enter table values or extend the table, formatting it just the way you want.
        You can use this in description and comment boxes all throughout GitLab.

        You can now also click on the link button, and this will generate the URL
        link syntax skeleton for you. Allowing you to quickly paste in a link and
        write the name of it.

        Thank you [George Tsiolis](https://gitlab.com/gtsiolis) for the table contribution!

        Thank you [Jan Beckmann](https://gitlab.com/kingjan1999) for the URL link contribution!

    - name: "Include new issues created in Burndown Chart"
      available_in: [starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/milestones/burndown_charts.html'
      image_url: '/images/11_4/burndown-chart.png'
      reporter: victorwu
      team: plan
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/6174'
      description: |
        Burndown Charts help teams track work, as it progresses throughout a milestone.
        Usually, the scope of work is decided and agreed on before the milestone
        begins. But occasionally, there will be important exceptions to the rule,
        (such as an emergency bug or security fix) and new scope needs to be included,
        in the form of new issues.

        With this release, burndown charts now accounts for these
        new issues that are created in the middle of a milestone, resulting in an
        uptick of its line.

    - name: "Expanded weight values in issues API"
      available_in: [starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/api/issues.html'
      reporter: victorwu
      team: plan
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/6822'
      description: |
        In a previous release, we expanded the allowable values of issue weight
        from a small number to effectively unlimited, any number greater than zero.

        With this release, we've brought this flexibility to the issues API as well,
        allowing users to set this field with the newly expanded number range with
        the API.

    - name: "Lock discussion quick action"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/quick_actions.html'
      image_url: '/images/11_4/lock-discussion-quick-action.png'
      reporter: victorwu
      team: plan
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/39173'
      description: |
        Locking discussions in issues and merge requests is helpful to direct conversations
        to newer issues (or merge requests). It can also be used to control abusive
        or otherwise unproductive behavior.

        With this release, we now have quick actions to lock and unlock discussions,
        making it easier to type a comment and lock/unlock all one action.

        Thank you [Mehdi Lahmam](https://gitlab.com/mehlah) for the contribution!

    - name: "Close epics"
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/group/epics/'
      image_url: '/images/11_4/close-epics.png'
      reporter: victorwu
      team: plan
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/7013'
      description: |
        Similar to issues and merge requests, you can now close (and re-open) epics
        in GitLab. The epics list now has the Open, Closed, and All tabs, just like
        issues. So when you have completed all the work in an epic, or it is no
        longer relevant, you can close it, and it won't appear anymore in the default
        list view.

        You can close (and re-open) an epic via buttons on the epic, via quick actions
        in an epic comment, and also via the API, exactly like issues.

    - name: "Improve Admin Area settings structure"
      available_in: [core, starter, premium, ultimate]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/ee/user/admin_area/settings/'
      image_url: '/images/11_4/admin-area-settings.png'
      image_noshadow: true
      reporter: akaemmerle
      team: manage
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/44998'
      description: |
        Depending on your responsibilities, administrating GitLab can provide
        a very complex challenge due to all things GitLab offers.

        With this release, we improve the experience of our Admin Area Settings by
        moving all sections into new, individual Settings sub-pages. This provides
        admins a time-saving shortcut to access any detail to manage.

    - name: "Explore projects by popularity"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/search/#projects'
      image_url: '/images/11_4/explore-projects-by-stars.png'
      image_noshadow: true
      reporter: akaemmerle
      team: manage
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/47203'
      description: |
        At GitLab, we do our best to enable you to explore relevant and cool projects
        on your GitLab instance.
        With this release, a new filter "Most stars" provides an incredible useful
        filter to show projects most starred on your instance.

        Thank you for this contribution, [Jacopo Beschi](https://gitlab.com/jacopo-beschi)!

    - name: "Display code language percentage on project overview"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/repository/#repository-languages'
      image_url: '/images/11_4/repo-code-language-percentage.png'
      reporter: akaemmerle
      team: manage
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/51457'
      description: |
        We recently introduced a new code language bar on the Project overview page,
        providing a quick overview about programming languages involved.

        With GitLab 11.4, we introduce an additional absolute measure by showing
        a new percentage value for each relevant code language shown. This provides
        a more quantitative view of your project's technology stack.

        Thank you for this contribution, [Johann Hubert Sonntagbauer](https://gitlab.com/johann.sonntagbauer)!

    - name: "Download two-factor recovery codes"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html#recovery-codes'
      image_url: '/images/11_4/2fa-codes-download.png'
      reporter: akaemmerle
      team: manage
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/47963'
      description: |
        Two-factor authentication is a de facto standard for signing up for any relevant web-based
        application. At GitLab we understand and take this seriously. Whenever you set up a two-factor
        authentication initially, we provide limited recovery codes that allow you to regain access
        to your account as a fallback.

        With this release, we now support download of recovery codes as a text
        file using the new "Download codes" button.

        Thank you for this contribution, [Luke Picciau](https://gitlab.com/Qwertie)!

    - name: "Filter admin Runners view by Runner type and state"
      available_in: [core, starter, premium, ultimate]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/ee/ci/runners/'
      image_url: '/images/11_4/runner-admin-filter.png'
      reporter: jyavorska
      team: release
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/36781'
      description: |
        The admin runner view now supports the ability to filter
        by runner type and state, giving you more options to manage
        especially large fleets of runners in your environment.

    - name: "Add support for interactive web terminal to Docker executor"
      available_in: [core, starter, premium, ultimate]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/ee/ci/interactive_web_terminal/'
      image_url: '/images/11_4/verify-webterm.png'
      reporter: jyavorska
      team: verify
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-runner/issues/3467'
      description: |
        The interactive web terminals feature has been expanded to be
        compatible with Docker executors as well. For now, the Docker session
        is closed as soon as the script exits, but we are aiming to further
        improve this behavior by resolving [#3605](https://gitlab.com/gitlab-org/gitlab-runner/issues/3605) in
        our next release.

    - name: "Skip Auto DevOps jobs based on feature availability"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/topics/autodevops/'
      reporter: danielgruesso
      team: configure
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/48399'
      description: |
        Starting in 11.4 Auto DevOps will now evaluate the plan (GitLab.com) or tier (self-managed)
        for the instance in which it's running in order to determine which jobs to skip. This will
        result in faster Auto DevOps pipeline when certain features are not in use.

        This will not only save you time but will also result in a cleaner view of Auto DevOps pipeline,
        showing you only the relevant jobs for your project.

    - name: "Allow pipelines to schedule delayed jobs"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/ci/yaml/README.html#when-delayed'
      image_url: '/images/11_4/verify-delayedjobruns.png'
      reporter: jyavorska
      team: verify
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/51352'
      description: |
        It is now possible to set a job to start after a delay
        via the `when` keyword in `.gitlab-ci.yml`. The timer starts
        ticking when the job would have otherwise started, giving you
        control to implement tasks that need to wait for a period of time to occur - for
        example, when implementing timed incremental rollouts, or any
        other delays needed after performing some other action.

    - name: "Interactive runbooks with Nurtch and JupyterHub"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/clusters/runbooks/'
      image_url: '/images/11_4/nurtch.png'
      reporter: danielgruesso
      team: configure
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/45912'
      description: |
        Interactive runbooks provide a powerful way for operators to interact with various systems to carry out
        common tasks such as diagnosing, deploying, and measuring infrastructure components.

        The JupyterHub app offered via GitLab's Kubernetes integration now ships with Nurtch's
        [Rubix library](https://github.com/amit1rrr/rubix), providing a simple way to create DevOps
        runbooks. A sample runbook is provided, showcasing [common operations](https://youtu.be/Q_OqHIIUPjE).

    - name: "Add manual entries for License Management"
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/application_security/license_compliance/#project-policies-for-license-compliance'
      image_url: '/images/11_4/license_management.png'
      reporter: bikebilly
      team: secure
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/5940'
      description: |
        License Management policy allows developers to define if they want to approve or blacklist
        a specific license for their project. This can be done as soon as a new license is introduced,
        directly in the merge request page. But sometimes project maintainers want to populate the
        list beforehand, so that developers already know if their changes are aligned with the policy.

        In GitLab 11.4, we introduce the ability to add manual entries for License Management. Project
        maintainers can prefill the policy in the **Settings > CI/CD > License Management** page by
        choosing from a set of common licenses, or add a custom entry to that list.

    - name: "Alert thresholds now displayed on metrics dashboard"
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#setting-up-alerts-for-prometheus-metrics'
      image_url: '/images/11_4/alert_threshold.png'
      reporter: joshlambert
      team: monitor
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/6036'
      description: |
        With GitLab 11.4, configured alert thresholds are now displayed directly on the metrics charts.
        This allows easier determination of which metrics are currently generating alerts, and better
        visualization of the interplay of the metric and alert threshold.

    - name: "Git protocol v2"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/administration/git_protocol.html'
      reporter: jramsay
      team: create
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/46555'
      description: |
        Developers fetch refs many times a day to check if the current branch
        is behind the remote branch. Git protocol v2 is a major update to Git's
        [wire protocol](https://www.kernel.org/pub/software/scm/git/docs/technical/pack-protocol.html)
        which defines how clones, fetches, and pushes are communicated between
        the client (your computer) and the server (GitLab). The new wire
        protocol improves the performance of fetch commands and enables future
        protocol improvements.

        Previously, all responses to fetch commands included a list of all
        references in the repository. For example, fetching updates for a
        single branch (e.g. `git fetch origin master`) would also retrieve a
        complete list of all references. In the case of large projects, this
        could be over 100,000 refs and 10s of megabytes of data.

        Git protocol v2 is supported from Git v2.18.0 and is opt-in. To enable
        globally run `git config --global protocol.version 2`. Git protocol v2
        over SSH is not yet enabled on GitLab.com and must be enabled manually
        for self-hosted installations.

    - name: "Geo UX improvements in Admin Area"
      available_in: [premium, ultimate]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/ee/administration/geo/replication/configuration.html'
      image_url: '/images/11_4/geo_admin_area_improvements.png'
      reporter: akaemmerle
      team: geo
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/7126'
      description: |
        As a Geo admin, keeping an overview of your secondary nodes setup and the synchronization
        state is crucial when working with distributed teams.

        With GitLab 11.4, we improve the Geo-related Admin Area settings by improving and showing even
        more synchronization and verification details in the user interface. On your primary node, a
        new button "Open projects" adds a new quick link to navigate to the "Projects" list of the
        corresponding secondary node.
        On secondary nodes, a new "All" tab gives you a quick overview about the verification state
        of all projects.

        [Further UX improvements](https://gitlab.com/groups/gitlab-org/-/epics/369) are in our pipeline!

    - name: "Prometheus 2.0 upgrade for Omnibus GitLab"
      available_in: [core, starter, premium, ultimate]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/omnibus/update/gitlab_11_changes.html#11-4'
      reporter: joshlambert
      team: monitor
      issue_url: 'https://gitlab.com/gitlab-org/omnibus-gitlab/issues/2940'
      description: |
        Omnibus GitLab comes out of the box with Prometheus, allowing [easy observability of deployed instances](https://docs.gitlab.com/ee/administration/monitoring/prometheus/).
        The Prometheus team has released a major new version, the 2.x series, which offers a
        [number of improvements](https://prometheus.io/blog/2017/11/08/announcing-prometheus-2-0/).
        These include improved performance and a more efficient time-series database format. Unfortunately
        because of the architectural changes to the database, it is not backwards compatible with the old 1.x format.

        With GitLab 11.4, Prometheus 2.4.2 is now available in the Omnibus package so users can take advantage of its benefits.

        - New installations of 11.4 and above will start with Prometheus 2.
        - Existing installations will not be automatically upgraded. We have added a new command, `gitlab-ctl prometheus-upgrade`, which can
        be utilized to [upgrade Prometheus and optionally migrate data](https://docs.gitlab.com/omnibus/update/gitlab_11_changes.html#11-4). Prometheus will be stopped during data migration.
        - GitLab 12.0 will [automatically upgrade to Prometheus 2.0](#deprecations). With the automatic upgrade, Prometheus 1.0 data will not be migrated.

        For more information on upgrading Prometheus to 2.4.2, please review our [update documentation](https://docs.gitlab.com/omnibus/update/gitlab_11_changes.html#11-4).

    - name: "Geo improvements"
      available_in: [premium, ultimate]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/ee/administration/geo/replication/configuration.html'
      reporter: akaemmerle
      issueboard_url: 'https://gitlab.com/groups/gitlab-org/-/boards/796982?scope=all&utf8=✓&state=opened&label_name[]=Geo&milestone_title=11.4'
      description: |
        We continually focus on improving our [Geo](/solutions/geo/) feature for distributed teams. Some of the additional noteworthy improvements in GitLab 11.4 include:

        - [Major performance improvements](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=✓&state=closed&label_name%5B%5D=Geo%20Performance&milestone_title=11.4)
        - [Include keep-around references in checksum calculation](https://gitlab.com/gitlab-org/gitlab-ee/issues/5196)
        - [Migrating uploads to object storage does no longer leave behind local files](https://gitlab.com/gitlab-org/gitlab-ee/issues/7108)
        - [Primary node repository verification now always gives the correct checksum](https://gitlab.com/gitlab-org/gitlab-ee/issues/7213)
        - [Reliable Sidekiq queueing ensures data integrity](https://gitlab.com/gitlab-org/gitlab-ee/issues/7279)

        Read our fresh blog post on [how we built GitLab Geo](/blog/2018/09/14/how-we-built-gitlab-geo/).

    - name: "Geo improvements for SSH Git commands proxy to primary node"
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/administration/geo/replication/configuration.html'
      image_url: '/images/11_4/geo_ssh_proxy_improvements.png'
      reporter: akaemmerle
      team: geo
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/7541'
      description: |
        Making Geo as easy to use as possible is one of our constant goals to support widely distributed
        teams using GitLab. In [11.3](https://about.gitlab.com/blog/2018/09/22/gitlab-11-3-released/#geo-improvements)
        we added initial support for proxying SSH `git push` from secondary nodes to primary nodes.

        With this release, we further improve the performance and usability of this feature, allowing
        to clone and push to projects in a Geo scenario without having to maintain multiple configurations or update the remote URL manually.

    - name: "GitLab Runner 11.4"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/runner'
      documentation_text: "Read through the documentation of GitLab Runner"
      description: |
        We're also releasing GitLab Runner 11.4 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:

        - [Support JSON logging](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1020)
        - [Add docker support for interactive web terminal](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1008)
        - [Add support docker machine web terminal support](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1046)
        - [Allow disabling docker entrypoint overwrite](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/965)
        - [Add metrics with concurrent and limit values](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1019)
        - [Add a gitlab_runner_jobs_total metric](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1018)
        - [Add a job duration histogram metric](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1025)
        - [Fix command and args assignment when creating containers with K8S executor](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1010)

        List of all changes can be found in GitLab Runner's [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/v11.4.0/CHANGELOG.md).

# Omnibus and performance

    - name: "Omnibus improvements"
      available_in: [core, starter, premium, ultimate]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/omnibus/'
      reporter: joshlambert
      team: distribution
      description: |
        - `redis` has been updated to 3.2.12, which is a critical security update that fixes multiple vulnerabilities. After upgrading to 11.4, run `sudo gitlab-ctl restart redis` to ensure the new version is running.
        - GitLab 11.4 includes [Mattermost 5.3](https://mattermost.com/blog/mattermost-5-3-enhanced-search-on-desktop-and-mobile-plugin-hackathon-highlights-and-more/),
        an [open source Slack-alternative](https://mattermost.com/) whose newest release includes enhanced search on desktop and mobile, plus much more.
        It includes [security updates](https://about.mattermost.com/security-updates/) and upgrading is recommended.
        - `git` has been updated to 2.18.1, and `libpng` to 1.6.35.
        - `gnupg` has been updated to 2.2.10, `gpgme` to 1.10.0, `libgcrypt` to 1.8.3, `npth` to 1.6, `libgpg-error` to 1.32, and `libassuan` to 2.5.1.
        - Certificates in the `trusted_certs` directory are now set to `0644` permissions instead of `0755`.

    - 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=11.4' # Link to the merged MRs in the corresponding milestone
      reporter: multiple
      team: multiple
      description: |
        Some of the more noteworthy performance improvements in GitLab 11.4 include:

        - [Rendering Markdown with many label references is faster](https://gitlab.com/gitlab-org/gitlab-ce/issues/48221)
        - [Issue discussions with many cross-project commit references are faster](https://gitlab.com/gitlab-org/gitlab-ce/issues/43094)
        - [Fetching related branches for an issue runs fewer queries](https://gitlab.com/gitlab-org/gitlab-ce/issues/43097)
        - [Fetching environments for a merge request runs fewer queries](https://gitlab.com/gitlab-org/gitlab-ce/issues/43109)
        - [Computing recipients for notification emails runs fewer queries](https://gitlab.com/gitlab-org/gitlab-ce/issues/47496)
        - [Creating a new diff discussion on a merge request is faster](https://gitlab.com/gitlab-org/gitlab-ce/issues/49002)
        - [Fetching "Last commit" info in tree view makes fewer Gitaly calls](https://gitlab.com/gitlab-org/gitlab-ce/issues/37433)
        - [Loading merge request is faster after removing dead code](https://gitlab.com/gitlab-org/gitlab-ce/issues/51172)

# MVP
mvp:
  fullname: "Luke Picciau"
  gitlab: Qwertie
  description: |
    Luke added the ability to
    [download 2FA recovery codes as a file](#download-two-factor-recovery-codes),
    making them easier to backup. 2FA recovery codes are needed to access your
    GitLab account if you lose access to your phone or one time password
    secret.

    Thank you, Luke for your contribution!

# COVER IMAGE LICENCE
cover_img:
  image_url: 'https://unsplash.com/photos/vn58Tq0L-bc'
  licence: Unsplash
  licence_url: 'https://unsplash.com/license'

# CTA BUTTONS
cta:
  - title: "Join us for an upcoming event"
    link: '/events/'
  - title: "Watch the 11.4 Release Radar webcast"
    link: 'https://youtu.be/2Dslcg3PJcs'

# UPGRADE BAROMETER
barometer:
  reporter: release-man
  description: |
    To upgrade to GitLab 11.4 from the latest 11.3 version, no downtime is required. To upgrade
    without downtime, please consult the [documentation on downtimeless upgrades](https://docs.gitlab.com/ee/update/README.html#upgrading-without-downtime).

    For this release we have migrations, post-deploy migrations, and to help with the larger
    migrations we have introduced background migrations.

    GitLab.com migrations took approximately 34 minutes and post-deploy migrations amounted for a
    total of around two minutes.

    This release includes a [critical security update for `redis`](#omnibus-improvements). We strongly recommend running `sudo gitlab-ctl restart redis` to ensure the new version is running.

    GitLab Geo users, please consult the documentation on [upgrading Geo](https://docs.gitlab.com/ee/administration/geo/replication/updating_the_geo_nodes.html).

    To ease setup, [Omniauth is now enabled by default](https://docs.gitlab.com/ee/integration/omniauth.html).
    As no external providers are automatically configured, this shouldn't affect
    most installations. However, if you have previously configured an external
    provider **without** enabling omniauth, it will be activated when upgrading
    to 11.4. To prevent this from happening, you can either remove the provider
    from your configuration, or [explicitly disable Omniauth](https://docs.gitlab.com/ee/integration/omniauth.html#disabling-omniauth).

# DEPRECATIONS
deprecations:
  - feature_name: "Support for Docker versions in GitLab Runner"
    due: October 22, 2018
    reporter: jyavorska
    description: |
      With GitLab 11.4 (October 22, 2018), support for Docker versions before 1.12 (API version 1.24) have been be deprecated in line with
      Docker's latest [version recommendation guidance](https://docs.docker.com/develop/sdk/#api-version-matrix). Beyond
      the 11.4 release these older versions are no longer be officially supported and could stop working at any time.
  - feature_name: "Support for Prometheus 1.x in Omnibus GitLab"
    due: GitLab 12.0
    reporter: joshlambert
    description: |
      With GitLab 11.4 (October 22, 2018) the bundled Prometheus 1.0 version is deprecated in Omnibus GitLab. Prometheus 2.0 is [now included](#prometheus-20-upgrade-for-omnibus-gitlab),
      however the metrics format is incompatible with 1.0. Existing installations can upgrade to 2.0 and optionally migrate their data [using an included tool](https://docs.gitlab.com/omnibus/update/gitlab_11_changes.html#11-4).

      With GitLab 12.0 any installation not yet running Prometheus 2.0 will be automatically upgraded. Metric data from Prometheus 1.0 will not be migrated, and will be lost.
