features:
# TOP FEATURE
  top:
    - name: GitLab CI/CD for external repos
      available_in: [premium, ultimate, free, bronze, silver, gold]
      documentation_link: 'https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos'
      documentation_text: "Read through the documentation on CI/CD for external repos"
      image_url: '/images/10_6/cicd_project.png'
      reporter: jramsay
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/4839'
      description: |
        In 2011, GitLab started out as a code repo alone. Since then, we've built an application for the entire DevOps lifecycle that includes rich capabilities for testing, security, packaging, deployment, and monitoring. With this newest release, you can now use GitLab for CI, or even CD and monitoring, all while your application code is hosted in an external repo.

        To use [GitLab CI/CD with a GitHub repository](/solutions/github/) create a new GitLab project. On the **CI/CD for external repo** tab, click **GitHub** to sign in and select your GitHub repo. Once you add a `.gitlab-ci.yml` file to your repo (or enable Auto DevOps), GitLab will automatically run pipelines and update the commit status in GitHub.

        You can also connect to any Git repo via URL and configure status webhooks manually. For example, if you're using Bitbucket, read how to
        [manually enable GitLab CI/CD](https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/bitbucket_integration.html).

        To celebrate this release, we're offering this feature promotionally as part of GitLab.com Free through March 2019.

# PRIMARY FEATURES
  primary:
    - name: Quick deploy of GitLab Runner to Kubernetes cluster
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/clusters/#installing-applications'
      documentation_text: "Read through the documentation on installing a runner on Kubernetes"
      image_url: '/images/10_6/runner.png'
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/32831'
      description: |
        GitLab gives you the ability to interact with Kubernetes clusters, and it
        also allows easy installation of applications that can be leveraged by your
        project.

        In GitLab 10.6 we add the ability to deploy a GitLab Runner directly on
        your cluster with a single click. It will be automatically available to run
        jobs for your project, without any further configuration needed.

    - name: Kubernetes cluster monitoring
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/clusters/#monitoring-your-kubernetes-cluster'
      documentation_text: "Read through the documentation on monitoring Kubernetes clusters"
      reporter: joshlambert
      image_url: '/images/10_6/cluster_monitoring.png'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/5029'
      description: |
        Kubernetes provides a great way for developers to easily deploy
        and manage applications, without worrying about how or where
        their software is running. It is still important however to
        manage overall cluster capacity, to balance room for growth
        versus underutilized compute costs.

        GitLab 10.6 makes this easy, by directly showing both the current
        and available compute resources for a connected cluster. For example if
        [deploy boards](https://gitlab.com/gitlab-org/gitlab-ee/issues/5029)
        is showing a pod that is failing to start, a user can simply check the
        cluster metrics to confirm if resources have been exhausted.

    - name: Ingress IP address on Kubernetes cluster page
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/clusters/#getting-the-external-ip-address'
      documentation_text: "Read through the documentation on Ingress address for Kubernetes clusters"
      image_url: '/images/10_6/ingress_ip.png'
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/42643'
      description: |
        In GitLab 10.2 we released the ability to [install an Ingress](https://about.gitlab.com/blog/2017/11/22/gitlab-10-2-released/#one-click-install-for-helm-and-ingress-on-kubernetes)
        in your Kubernetes cluster. Once installed, the Ingress provides a
        public IP address that allows external access to your deployed applications.

        In GitLab 10.6, you can see the IP address assigned to your Ingress controller
        directly from the Kubernetes page in the UI, and use it to configure a domain
        name to access your applications from the internet.

    - name: Maintainers can push to MR from fork
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/merge_requests/maintainer_access.html'
      documentation_text: "Read through the documentation on maintainers access"
      image_url: '/images/10_6/allow_maintainers_to_edit.png'
      reporter: jramsay
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/22292'
      description: |
        Forking workflows are common in open source projects like GitLab, where
        contributors submit merge requests from their fork of the project back
        to the upstream project.

        When reviewing merge requests from forks, maintainers of the upstream
        project can now make small fixes or rebase before merging, reducing the
        back and forth of accepting community contributions. Of course,
        maintainers aren't limited to small fixes and can help out by adding
        large commits to the merge request too!

        Prior to this release, maintainers could not directly contribute
        to a merge request from a fork since maintainers do not automatically
        receive write permissions to forks. With this release, if the merge
        request author has write access to the source branch of the merge
        request, they can grant maintainers write access to the source branch
        of the merge request by enabling **Allow edits from maintainers** on the
        merge request. When enabled, users with merge permissions to the target
        branch of the upstream project will be able to push to the source
        branch of the merge request. By default, it is turned off.

    - name: Single Group Issue Board in Core and Free
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/issue_board.html'
      documentation_text: "Read through the documentation on Issue Boards"
      image_url: '/images/10_6/one-group-board-libre.png'
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/38337'
      description: |
        GitLab's Group Issue Board allows you to manage issues from multiple projects all at once. You can see issues from projects within the same group all within the same interface, and move them across workflow stages, all in one interface.

        This feature was previously available exclusively in the Premium and Ultimate tiers. And users in
        these tiers have found it to be very useful. GitLab Core users have also asked for this feature, and
        they have said providing one group issue board would be a great addition to their workflows. So that's what we have shipped
        in this release. Core and Starter instances now have one group issue board per group,
        and multiple group issue boards remain reserved for Premium and Ultimate. Correspondingly,
        GitLab.com Free and Bronze also have one group issue board per group, with multiple group issue boards
        continuing to be in GitLab.com Silver and Gold. We think this adds significant value to the Core and GitLab.com
        Free tiers, and helps even more users better evaluate and provide
        feedback on the feature itself.

# SECONDARY FEATURES
  secondary:
    - name: SAST security report on pipelines view
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/application_security/sast/#security-report-under-pipelines'
      documentation_text: "Read through the documentation on SAST security reports in the pipeline view"
      image_url: '/images/10_6/sast_report.png'
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/3776'
      description: |
        A few releases ago, we shipped [Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/topics/autodevops/#auto-sast),
        which automatically finds vulnerabilities in any new code changes in a merge request.
        This allows you to fix them before merging, ensuring these security problems are not introduced
        nto master and not released to production.

        With this release, this same information is available in a complete SAST security report
        in the **CI/CD > Pipelines** page. This allows developers, production/systems engineers, and
        any other security stakeholders to have even more visibility into any security risks as your code
        progresses through CI/CD.

    - name: SAST for Java-Maven apps
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/topics/autodevops/#auto-sast'
      documentation_text: "Read through the documentation on SAST"
      image_url: '/images/10_6/sast_maven.png'
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/4123'
      description: |
        Prior to this release, GitLab already supported popular languages such as Ruby, Python, and JavaScript as part of
        [Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/topics/autodevops/#auto-sast) feature.

        In GitLab 10.6, we are adding Maven, a common build automation tool for Java.
        If you are already using SAST, you don't need to change anything in your configuration to get the new checks; they will
        be automatically available.

        See the [complete list of supported languages and frameworks](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks).

    - name: External Authorization Control
      available_in: [premium, ultimate]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/ee/user/admin_area/settings/external_authorization.html'
      documentation_text: "Read through the documentation on External Authorization Control"
      reporter: jramsay
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/4216'
      description: |
        In some regulated environments, project classification systems are used
        to control access to projects, and can now be used with GitLab. When
        enabled, admins can set the classification of each project. In addition
        to GitLab access controls, access to projects will also require
        approval from the external authorization service.

    - name: Authentication support for DAST
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/application_security/dast/'
      documentation_text: "Read through the documentation on Authentication support for DAST"
      image_url: '/images/10_6/dast_auth.png'
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/security-products/zaproxy/issues/1'
      description: |
        A few releases ago, we shipped [Dynamic Application Security Testing (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/),
        allowing you to check for security vulnerabilities dynamically and automatically in a [Review App](https://docs.gitlab.com/ee/ci/review_apps/index.html)
        version of your work-in-progress code, before it is merged into master and released to production.

        Previously, this feature was limited to public pages. With this release, you can now specify credentials that DAST
        will use to authenticate into your web app and to simulate an attacker that is able to access sections protected
        with a login process.

    - name: External CI/CD configuration in Starter and Bronze
      available_in: [starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/ci/yaml/#include'
      documentation_text: "Read through the documentation on including external CI/CD configuration"
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/43818'
      description: |
        In GitLab 10.5 we added the ability to [include external CI/CD configuration files](https://about.gitlab.com/blog/2018/02/22/gitlab-10-5-released/#include-external-files-in-cicd-pipeline-definition)
        into the main `.gitlab-ci.yml` for your project. This feature was available only to Premium users on self-hosted Gitlab and Silver users on GitLab.com.

        We received a lot of feedback from customers asking us to move this to a lower tier and we are excited
        to bring this feature to even more users in this release by making it now available to Starter users on self-hosted Gitlab and Bronze users on GitLab.com.
        The ability to have a centralized control over the pipeline configuration
        and to reuse the same definition in multiple projects is something that is valuable for enterprises and smaller businesses as well.

        Note that as part of our commitment to open source, public projects on Free GitLab.com
        have features equivalent to a Gold level subscription. So those public projects will continue to have this feature.

    - name: Branches overview
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/repository/branches/index.html'
      documentation_text: "Read through the documentation on Branches"
      image_url: '/images/10_6/branches_overview.png'
      reporter: jramsay
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/17293'
      description: |
        As projects and teams grow, so do the number of branches. The new
        branches overview and filtered branches lists make it easy to quickly
        find the branch you're looking for. Branches with a commit added in
        the last three months are shown as active.

        Thank you [Takuya Noguchi](https://gitlab.com/tnir) for the
        [contribution](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15402)!

    - name: Navigate to external issue tracker
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/integration/external-issue-tracker.html'
      documentation_text: "Read through the documentation on External Issue Tracker"
      image_url: '/images/10_6/external-tracker-nav.png'
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/37050'
      description: |
        Some teams use GitLab integrated with an external issue tracker. For example,
        Jira issues integrated with GitLab merge requests is a popular workflow for many teams.
        In this scenario, GitLab issues still function as normal, and teams are free
        to use them, for example, in separate one-off scenarios where a team wants everything just in GitLab.

        To streamline this integration, we've added a new link to the project navigation.
        If you have configured any external issue tracker (Redmine, Jira, Bugzilla, or the Custom Issue Tracker),
        there will be a separate link in the project navigation that allows you to quickly navigate to that
        external system. The GitLab issues link remains so that there's no confusion and also allows you to
        use both issue trackers if you want.

    - name: Project import/export API
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/api/project_import_export.html'
      documentation_text: "Read through the documentation on Project Import/Export API"
      reporter: jramsay
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/41899'
      description: |
        Projects are extremely important in GitLab, since they contain all the valuable
        work (including the Git repo) and organization (including issues and merge requests) of your team.
        Using the existing project export and import features of GitLab,
        projects can easily be transferred within and between instances.

        Up to now, this was a manual process. With this release, project
        exports and imports are now part of the GitLab API, allowing you even
        more automated and flexible workflows when you need move your projects
        within or between GitLab instances.

        Thank you [Travis Miller](https://gitlab.com/travismiller) for the
        [contribution](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15860)!

    - name: Labels in Epics
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/group/epics/' #CHECK for update
      documentation_text: "Read through the documentation on Epics"
      image_url: '/images/10_6/epics-labels.png'
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/3727'
      description: |
        GitLab issues and merge requests support labels to enable flexible and highly
        customizable management of these objects. It's an effective design that we've
        also brought to Epics in this release.

        You can now assign group labels to epics from the sidebar of an epic, exactly
        the same as with issues and merge requests. And you can filter by labels on the epics
        list page in a group, again like issues and merge requests. Users of GitLab
        will thus find this feature immediately recognizable. This allows you easily
        mix and match epics into different categories based on the powerful search and filter bar.

    - name: GitLab ChatOps (alpha)
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/ci/chatops/'
      documentation_text: "Read through the documentation on GitLab ChatOps"
      reporter: joshlambert
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/4856'
      description: |
        For many organizations, much of their communication, including their
        operations and troubleshooting discussions, is moving to chat. There
        is also typically an "operations toolbox," containing frequently used
        commands to check on the health of an environment or to perform routine actions.

        With GitLab 10.6 we wanted to make it easy to both automate these routine
        actions, as well as bring them into Slack itself. Getting started is as
        easy as adding a job to your GitLab CI YML, and enabling Slack
        slash commands integration. Users will then be able to interact with it by typing
        in the slash command, the CI job name, and then passing any relevant
        arguments. The job will be executed on a runner, with the output being
        sent right back to Slack.

    - name: Epics API
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/api/epics.html'
      documentation_text: "Read through the documentation on Epics API"
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/4732'
      description: |
        Along with the labels support mentioned [above](#labels-in-epics), we have maintained
        parity with API support for Epics. You can get a list of epics based on the same search
        and filter parameters of the search and filter bar in the web UI of the epics page. This includes
        searching by the epic title and description, filtering by the author and labels, and ordering
        by "created at" and "updated at" timestamps.

    - name: Merge Request Approvals API
      available_in: [starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/api/merge_request_approvals.html' #CHECK for update
      documentation_text: "Read through the documentation on Merge Request Approvals API"
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/183'
      description: |
        Prior to this release, the Merge Request Approvals API was limited to
        approving and unapproving a merge request only. With this release,
        you can now fully configure approvals at the project level and at the
        merge request level, giving users feature parity with the GitLab web UI.

        With the Approvals API, teams can now create more elaborate code review
        and approval workflows that are specific to their needs. You can use as much
        or as little of the API as needed to customize which parts of your workflow
        happen inside the GitLab web UI, and which parts happen outside.

    - name: Discussions API
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/api/discussions.html'
      documentation_text: "Read through the documentation on Discussions API"
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/41860'
      description: |
        With this release, we have brought API support to discussions in issues,
        snippets, and epics. This means that all comments and discussions (for issues)
        are now accessible via the API. Teams can leverage this API for flexible,
        customized, and specific workflows that are not necessarily in the main GitLab
        web UI.

        API support for comments and discussions in merge requests will
        also come [in a future release](https://gitlab.com/gitlab-org/gitlab-ce/issues/20901).

    - name: Business and other custom metrics
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#adding-additional-metrics'
      documentation_text: "Read through the documentation on adding business and other custom metrics"
      reporter: joshlambert
      image_url: '/images/10_6/custom_metrics.png'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/2273'
      description: |
        Since [GitLab 9.0](https://about.gitlab.com/blog/2017/03/22/gitlab-9-0-released/#environment-monitoring-ce-ees-eep),
        developers have been able to monitor critical system and response
        metrics of their deployed apps, like throughput, latency, and
        CPU/memory utilization.

        This provided a great baseline understanding of both the user
        experience your customers were receiving as well as resource
        utilization, directly in the tool they use every day.

        With GitLab 10.6 we have added the ability to add your own metrics,
        allowing deeper introspection of your application and business. For example
        metrics from a credit card processing module can be added, tracking
        not just success rates but also revenue and order size. This can help surface
        failures that may not result in HTTP errors, as well as the ultimate impact
        on business performance.

        To get started, simply provide the Prometheus [PromQL query](https://prometheus.io/docs/prometheus/latest/querying/basics/) and it
        will begin to display in the dashboard.

    - name: Filipino, Indonesian, and Turkish language support
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/development/i18n/index.html'
      documentation_text: "Read through the documentation on translating GitLab"
      reporter: jramsay
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/4012'
      description: |
        As part of our ongoing effort to internationalize GitLab, we have now
        added support for Filipino, Indonesian and Turkish translations.

        We have also externalised strings on the Repository Locked Files
        (Premium and above) list page allowing our translation community to add
        more languages and strings to GitLab.

        If you are interested in contributing to GitLab’s internationalization
        efforts, we welcome you to join our
        [translation community](https://docs.gitlab.com/ee/development/i18n/index.html).

    - name: Cloud native GitLab Helm chart (alpha)
      available_in: [premium, ultimate]
      gitlab_com: false
      documentation_link: 'https://gitlab.com/charts/gitlab/blob/master/README.md'
      documentation_text: "Read through the documentation on GitLab Helm chart"
      reporter: joshlambert
      issue_url: 'https://gitlab.com/charts/gitlab/issues/187'
      description: |
        We are excited to announce that the cloud native GitLab
        [Helm](https://helm.sh) chart is now in alpha, and available
        for testing. This chart features a more cloud native architecture,
        with a container for each component of GitLab and no requirement
        for shared storage. These changes result in increased resilience,
        scalability, and performance of GitLab on Kubernetes.

        It is important to note that the chart and containers are still
        in active development, contain
        [known issues and limitations](https://gitlab.com/charts/gitlab/blob/master/doc/architecture/alpha.md#known-issues-and-limitations),
        and should not be used for production. For this release
        [GitLab Premium](https://about.gitlab.com/pricing/self-hosted/feature-comparison/) is required, while we work to bring
        [Object Storage support to Core](https://gitlab.com/gitlab-org/gitlab-ce/issues/40781).

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

        ##### Most interesting changes:

        * [Add `CI_RUNNER_VERSION`, `CI_RUNNER_REVISION`, and `CI_RUNNER_EXECUTABLE_ARCH` job environment variables](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/788)
        * [Always prefer creating new containers when running with Docker Executor](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/818)
        * [Use IAM instance profile credentials for S3 caching](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/646)
        * [exec command is no longer deprecated](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/834)
        * [Print a notice when skipping cache operation due to empty cache key](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/842)
        * [Switch to Go 1.9.4](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/827)

        List of all changes can be found in GitLab Runner's [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/v10.6.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/README.html'
      documentation_text: 'Read through the documentation on Omnibus GitLab'
      reporter: joshlambert
      description: |
        * GitLab [Mattermost 4.7](https://about.mattermost.com/releases/mattermost-4-7/) includes enhanced image preview and thumbnails, faster load times, upgraded desktop app, and [security updates](https://about.mattermost.com/security-updates/). Upgrading is recommended.
        * Chef has been updated to 13.6.4
        * Omnibus has been updated to 5.6.10.
        * PostgreSQL has been updated to 9.6.8.
        * Python has been updated to 3.4.8.
        * jemalloc has been updated to 5.0.1.
        * `announce-ip` and `announce-port` are now configurable for Redis/Sentinel, to better support HA in Docker environments.

    - 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=10.6
      documentation_text: See all the performance improvements in GitLab 10.6
      reporter: various
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/12345'
      description: |
        Some of the more noteworthy performance improvements in GitLab 10.6
        include:

        * [Project and group search results are restricted to 1,000 entries, to prevent database timeouts](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/17452)
        * [Fix a Gitaly N+1 when viewing a merge request](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/17630)
        * [Fix a Gitaly N+1 when viewing a merge request's diffs](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/17659)
        * [Cache conflicts resolvable status, to improve speed of merge request widget polling](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/17589)
        * [Improve response time for listing user activity](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/17454)

# MVP
mvp:
  fullname: Takuya Noguchi
  gitlab: tnir
  description: |
    This release's MVP is Takuya Noguchi. Takuya implemented a [re-designed and extremely useful branches page](#branches-overview) in GitLab,
    making it much easier to manage active versus stale branches, especially in large projects with many ongoing branches.

    Thank you, Takuya for your contribution! We’ve sent Takuya some GitLab swag as a thank you, including a hoodie, socks, and a handmade tanuki.

# COVER IMAGE LICENCE
cover_img:
  image_url: 'https://unsplash.com/photos/pVMMiTfk_EA'
  licence: Unsplash free license
  licence_url: 'https://unsplash.com/license'

# CTA BUTTONS
cta:
  - title: "Join us for an upcoming event"
    link: '/events/'

# UPGRADE BAROMETER
barometer:
  reporter: rspeicher
  description: |
    To upgrade to GitLab 10.6 from the latest 10.5 version, no downtime is required.

    For this release we have migrations and post-deploy migrations.

    GitLab.com migrations took approximately 30 minutes and post-deploy migrations accounted for about 10 minutes.

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

# DEPRECATIONS
deprecations:
  - feature_name: Mattermost configuration changes
    due: GitLab 11.0.
    reporter: joshlambert
    description: |
      With the release of GitLab 11.0, the number of Mattermost configuration
      options supported within `gitlab.rb` will be reduced. We will continue to
      support the
      [core configuration settings](http://docs.gitlab.com/omnibus/gitlab-mattermost/#upgrading-gitlab-mattermost-from-versions-prior-to-11-0)
      necessary to run Mattermost, and set up the integration with GitLab.
      Going forward, other configuration settings should be set directly within
      the Mattermost console, or
      [passed as environment variables](http://docs.gitlab.com/omnibus/gitlab-mattermost/#upgrading-gitlab-mattermost-from-versions-prior-to-11-0).

      Presently with two applications attempting to write to the same config
      file, changes can be lost.

  - feature_name: 'The legacy <code>gitlab</code> Helm chart'
    due: March 22, 2018.
    reporter: joshlambert
    description: |
      The legacy [`gitlab` Helm chart](https://docs.gitlab.com/ee/install/kubernetes/gitlab_chart.html)
      is deprecated. For installations on Kubernetes today, we recommend the
      beta [`gitlab-omnibus` Helm chart](https://docs.gitlab.com/ee/install/kubernetes/gitlab_omnibus.html).

      A new [cloud native GitLab chart](#cloud-native-gitlab-chart-is-alpha-available-for-testing)
      is in development with increased scalability, resilience, and other
      benefits. This chart will replace both existing charts when generally available
      later this year.

      For more information on GitLab Helm charts, please read the documentation on
      [installing GitLab on Kubernetes](https://docs.gitlab.com/ee/install/kubernetes/).
