features:
  top:
    - name: "SAST support for JavaScript"
      available_in: [ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/application_security/sast/"
      image_url: "/images/11_8/sast-javascript.png"
      reporter: bikebilly
      stage: secure
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ee/issues/5473"
      description: |
        Static Application Security Testing (SAST) allows you to spot vulnerabilities
        in your source code every time you commit a new change to the repository.
        With this information available in the merge request, you can shift security left
        and address problems even before they are merged into the stable branch.

        With 11.8, we add JavaScript to the list of languages supported by SAST.
        You don’t need to change anything in your pipelines. JavaScript projects are
        automatically detected and analyzed for security vulnerabilities. It is also
        part of [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/#auto-sast-ultimate).

  primary:
    - name: "Error tracking with Sentry"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/operations/error_tracking.html"
      image_url: "/images/11_8/error-tracking.png"
      reporter: joshlambert
      stage: monitor
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/55178"
      description: |
        Keeping an eye on errors generated by your application helps maintain a good user experience
        by detecting problems before users report them and speeding up resolution when they occur.

        GitLab 11.8 makes it more convenient and efficient to monitor errors by integrating with
        popular open source error tracker Sentry, and displaying the most recent errors right within your GitLab project.

        Sentry has recently [improved their GitLab integration](/blog/2019/01/25/sentry-integration-blog-post/),
        enabling detection of suspicious commits, release and commit tracking, and more. With the combination of both integrations
        you'll have a simple path to Sentry from GitLab, as well as a clean way to get to GitLab from Sentry, so that
        you can always address errors contextually, staying within your existing workflow.

    - name: "Create Pages sites in one click using bundled templates"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/pages/#getting-started"
      image_url: "/images/11_8/release-pagestemplates.png"
      reporter: jyavorska
      stage: release
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/47857"
      description: |
        We are now bundling our most popular Pages templates directly in
        GitLab, opening up the possibility of creating your sites directly
        from the new project creation screen instead of having to fork
        a sample repository as before.

        Check out our [blog post about using GitLab Pages templates](/blog/2019/02/20/start-using-pages-quickly/) for more.

    - name: "Pages support for subgroups"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/administration/pages/"
      image_url: "/images/11_8/release-pages-subgroups.png"
      reporter: jyavorska
      stage: release
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/30548"
      description: |
        Pages have been updated to work with subgroups in GitLab, giving
        you the ability to create Pages sites there as well. Sites
        set up in this way will have a URL in the format of
        `toplevel-group.gitlab.io/subgroup/project`. This will give your
        projects, even when part of subgroups, access to the ability to
        create documentation or other sites needed as part of releasing
        your software.

    - name: "Merge Request Approval Rules"
      available_in: [premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_approvals.html#multiple-approval-rules-premium"
      image_url: "/images/11_8/mr-approval-rules.png"
      reporter: jramsay
      stage: create
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ee/issues/1979"
      description: |
        Code review is an essential practice of every successful project, but
        who should review the changes is not always clear. It is frequently
        desirable to have a variety of reviewers from different teams like
        Engineering, UX, and Product.

        Approval Rules, new in GitLab 11.8, allow you to better communicate who
        should participate in code reviews by specifying the eligible
        approvers and the minimum number of approvals for each. Approval rules
        are shown in the merge request widget so the next reviewer can quickly
        be assigned.

        In GitLab 11.3 we introduced
        [Code Owners](/blog/2018/09/22/gitlab-11-3-released/#code-owners)
        to indicate which team members are responsible for which code in your
        project. Code owners are integrated into approval rules so that finding
        the right people to review your change is always easy.

        Approval Rules are disabled by default in 11.8 and must be enabled by
        an instance administrator by executing
        `Feature.enable(:approval_rules)` in the rails console.

        Approval Rules have temporarily been disabled on GitLab.com. We expect
        to be re-enabled after deploying GitLab 11.8.1. Follow
        [this issue](https://gitlab.com/gitlab-org/gitlab-ee/issues/9913)
        for updates.
        {: .alert .alert-info}

    - name: "Improved cross-project pipeline triggers"
      available_in: [premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/ci/yaml/#trigger"
      image_url: "/images/11_8/multi_project_pipeline_graph.png"
      reporter: brendan
      stage: verify
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ee/issues/8997"
      description: |
        Starting with [GitLab 9.3](https://about.gitlab.com/blog/2017/06/22/gitlab-9-3-released/#multi-project-pipeline-graphs), you've been able to create [multi-project pipelines](https://docs.gitlab.com/ee/ci/multi_project_pipelines.html)
        by triggering a downstream pipeline via a GitLab API call in your job. In 11.8, we've added first-class support for triggering
        these downstream pipelines with the `trigger:` keyword, which can be added to a bridge job to automatically trigger a downstream pipeline when the current pipeline succeeds.

    - name: "Improved squash commit messages"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/merge_requests/squash_and_merge.html"
      image_url: "/images/11_8/override-squash.png"
      reporter: jramsay
      stage: create
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/47149"
      description: |
        Creating Git history that is readable and useful to people in the
        future can be at odds with pushing small commits to fix a unit test
        or resolve feedback. Commit squashing combines all these commits into
        a single tidy change, but at the same time wipes out your thoughtful
        commit messages.

        GitLab now defaults the squash commit message to the first multi-line
        commit message in the feature branch, and allows you to override the
        commit message so that you can update it to reflect any important
        changes.

    - name: "Auto DevOps support for environment-specific custom domain"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/topics/autodevops/#environment-variables"
      image_url: "/images/11_8/auto-devops-hosts.png"
      reporter: danielgruesso
      stage: configure
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/46954"
      description: |
        Auto DevOps allows you to quickly get started by adding a "base domain" for your projects.
        When your application is ready for production deployment, you may then want to use a
        custom, fully qualified domain name.

        You can now use the environment variable `ADDITIONAL_HOSTS` to specify one or more custom
        domains for your application. Furthermore, you can scope it to a specific environment
        by prepending the environment name to the variable, ie. `<ENVIRONMENT>_ADDITIONAL_HOSTS`.

        Thank you [Aaron Walker](https://gitlab.com/walkafwalka) for the contribution!

    - name: "Show function scale for Knative functions"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/clusters/serverless/#deploying-functions"
      image_url: "/images/11_8/function-scale.png"
      reporter: danielgruesso
      stage: configure
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/54715"
      description: |
        Deploying functions using GitLab Serverless comes with all the benefits of Knative, such as
        scaling your serverless deployments up and down to zero.

        You can now see the scale of your serverless deployments for each application or function
        deployed to your Knative instance. Scale is illustrated by the number of Kubernetes
        pods currently in use.

  secondary:
    - name: "Specify the first day of the week"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/profile/preferences.html"
      image_url: "/images/11_8/first-day-of-week.png"
      reporter: jeremy
      stage: manage
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/2105"
      description: |
        Before, calendars in GitLab assumed that weeks began on Sunday. Users
        can now elect in their profile preferences to have their first day of the
        week begin on Monday, which is reflected throughout the application in
        date pickers and contribution graphs.

        Thank you [Fabian Schneider](https://gitlab.com/fabsrc) for the contribution!

    - name: "Scroll roadmap forward into the future and backward into the past"
      available_in: [ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/group/roadmap/"
      image_url: "/images/11_8/roadmap-scrolling.png"
      reporter: victorwu
      stage: plan
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ee/issues/7325"
      description: |
        When you first load the roadmap view, GitLab preselects a time period for you,
        with options to select weekly, monthly, or quarterly intervals. But the
        view was fixed, and epics outside of what was displayed were hidden.
        

        With this release, you can now scroll forward into the future and backward
        into the past. Epics that fall in these expanded times will automatically
        appear in the view, without requiring you to refresh the page in any way,
        allowing you a seamless experience to see even more epics in as long of a
        timeline you need.

    - name: "Authenticate credentials from a smart card with LDAP"
      available_in: [premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/administration/auth/smartcard.html"
      reporter: jeremy
      stage: manage
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ee/issues/7693"
      description: |
        Organizations using smart cards as authentication tokens frequently use LDAP
        for centralized identity management. In 11.8, we're iterating on the smart card
        authentication [added in 11.6](https://gitlab.com/gitlab-org/gitlab-ee/issues/726) by
        allowing credentials on a smart card to be authorized against a configured LDAP server.

        GitLab's approach follows [RFC4523](https://tools.ietf.org/html/rfc4523) schema standards
        using the `certificateExactMatch` rule.

    - name: "Feature Flags for Environments"
      available_in: [premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/operations/feature_flags.html#define-environment-specs"
      image_url: "/images/11_8/release-featureflagenvs.png"
      reporter: jyavorska
      stage: release
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ee/issues/8621"
      description: |
        It is now possible to individually turn feature flags on or off on a per-environment
        basis. The behavior of your feature flags is controlled by creating a set of rules based
        on matching the environment name. There is always a default wildcard rule (`*`), but you are also able to add
        more rules by adding more environment specs (for example, `review/*`).
        
        In 11.8.0 this feature will require enabling the feature flag, by executing 
        `Feature.enable(:feature_flags_environment_scope)` in the rails console.

    - name: "Upgrade Kubernetes Runner application via Kubernetes integration"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/clusters/#installing-applications"
      image_url: "/images/11_8/runner-upgrade.png"
      reporter: danielgruesso
      stage: configure
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/49384"
      description: |
        Keeping your Kubernetes-deployed apps running on the latest version ensures you have
        the newest features as well as up-to-date security.

        GitLab 11.8 allows you to upgrade the GitLab runner running in Kubernetes with a single click.
        Future releases will include similar functionality for the rest of the applications.

    - name: "User activity and creation dates shown in admin panel"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/api/users.html#for-admins"
      image_url: "/images/11_8/last-activity-users-admin.png"
      reporter: jeremy
      stage: manage
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/43681"
      description: |
        Understanding the activity level of users in GitLab should be an easy task
        for instance administrators. To help, we've added user creation date and
        the date of a user's last activity to the Users area of the admin panel
        at `/admin/users`.

        You can read more about the types of actions GitLab considers activity [here](https://docs.gitlab.com/ee/user/instance_statistics/user_cohorts.html).

    - name: "Record of a user's last activity in GitLab now includes browsing"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/instance_statistics/user_cohorts.html"
      reporter: jeremy
      stage: manage
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/54947"
      description: |
        GitLab includes a user attribute, `last_activity_on`, to help admins understand
        when a user's last activity was taken. This is very helpful for finding active and
        inactive users.

        To ensure we're capturing read-only activity, we've expanded last_activity_on to
        update on visits to pages related to dashboards, projects, issues, and merge requests.

    - name: "Project tags are now project topics"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/settings/#general-project-settings"
      reporter: jeremy
      stage: manage
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/54167"
      description: |
        Project tags are a useful way to organize related projects, but the term "tag" collided with
        Git tags. To resolve this, we've renamed project tags to project topics and [improved their presentation](https://gitlab.com/gitlab-org/gitlab-ce/issues/54544)
        on the project overview page.

        We're excited to make topics more useful for project discoverability, and are
        [adding topic filtering](https://gitlab.com/gitlab-org/gitlab-ce/issues/54372) to the project dashboard
        in 11.9.

    - name: "Search repository tags in a project via the API"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/api/tags.html"
      reporter: jeremy
      stage: manage
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/54401"
      description: |
        You can now search for repository tags in a project via the
        [Tags API](https://docs.gitlab.com/ee/api/tags.html). This makes finding
        a specific tag in a project more straightforward; if you're looking
        for related projects that match a specific version tag, you're now able
        to find matching projects with ease.

        Thank you [Robert Schilling](https://gitlab.com/razer6) for the contribution!

    - name: "Improved project lists with more information density"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/"
      image_url: "/images/11_8/project-list.png"
      reporter: jeremy
      stage: manage
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/56543"
      description: |
        We've responded to user feedback on our [first project list redesign](https://gitlab.com/gitlab-org/gitlab-ce/issues/51944)
        by improving the information density on this page with an additional
        column and less whitespace.

    - name: "Improved group overview with reduced white space"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/group"
      image_url: "/images/11_8/group-overview.png"
      reporter: jeremy
      stage: manage
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/53104"
      description: |
        In 11.8, we've made the group overview more information dense with a redesign. We've
        reduced the amount of whitespace on this page and aligned the user experience with the
        [project overview redesign](https://gitlab.com/gitlab-org/gitlab-ce/issues/44704).

        This is the first iteration of a [larger set of improvements](https://gitlab.com/gitlab-org/gitlab-ce/issues/50836)
        to the group overview page, and we're excited to continue iterating on this page.

    - name: "Child Epics in Epics API"
      available_in: [ultimate]
      documentation_link: "https://docs.gitlab.com/ee/api/epic_links.html"
      reporter: victorwu
      stage: plan
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ee/issues/7326"
      description: |
        In our previous release, we launched [child epics](https://docs.gitlab.com/ee/user/group/epics/#multi-level-child-epics),
        the ability to attach epics to epics. With this release, you can now manage
        these epic relationships via the API as well. So you can now manage customized
        workflows in your teams, especially through automation.

    - name: "Redesigned related merge requests, consistent with related issues"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/issues/crosslinking_issues.html#from-merge-requests"
      image_url: "/images/11_8/restyled-related-merge-requests.png"
      reporter: victorwu
      stage: plan
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/47007"
      description: |
        We've restyled the related merge requests section in an issue, to bring
        visual consistency to related issues and improve aesthetic appearance.

        We're even [adding more metadata](https://gitlab.com/gitlab-org/gitlab-ce/issues/51862)
        to each row in the design in a future release, to help users see relevant
        merge request information even more quickly and in context.

    - name: "Move Auto DevOps domain from CI/CD settings to cluster settings"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/topics/autodevops/#auto-devops-base-domain"
      image_url: "/images/11_8/auto-devops-base-domain.png"
      reporter: danielgruesso
      stage: configure
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/52363"
      description: |
        Specifying a base domain for Auto DevOps allows you to take advantage of powerful features such as
        Auto-Review Apps and Auto-Deploy. We've now made it even easier to specify the base domain by
        moving it directly to cluster settings. This will make it simple to define the base domain when
        the cluster is created, and also to define different domains for different clusters.

    - name: "Manage group labels via the API"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/api/group_labels.html"
      reporter: victorwu
      stage: plan
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/44901"
      description: |
        You can now manage group labels via the API, similar to project labels,
        helping further support customized planning and execution workflows
        on your teams.

        Thank you [Robert Schilling](https://gitlab.com/razer6) for the contribution!

    - name: ".html extensions are now automatically resolved for Pages sites"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/pages/"
      reporter: jyavorska
      stage: release
      issue_url: "https://gitlab.com/gitlab-org/gitlab-pages/issues/95"
      description: |
        A file in your Pages site called `/sub-page.html` can now also be
        accessed as `/sub-page`, giving you more options over how your
        site appears to your users.

    - name: "Predefined Pages variables in CI"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/pages/"
      reporter: jyavorska
      stage: release
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/42966"
      description: |
        `CI_PAGES` and `CI_PAGES_URL` have been added as CI variables for
        Pages pipelines, giving you visibility into the Pages domain name
        and URL. This allows for more flexibility when working with
        Pages sites hosted in multiple locations.

    - name: "Add tolerations to Kubernetes executor"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/runner/executors/kubernetes.html#the-keywords"
      reporter: brendan
      stage: verify
      issue_url: "https://gitlab.com/gitlab-org/gitlab-runner/issues/2681"
      description: |
        Kubernetes provides an exciting opportunity to disconnect the underlining hardware from where our workloads run. However, some tasks require specialized hardware – including jobs that may require more resources than others.

        Kubernetes supports this by introducing [taint and toleration](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to nodes in order to include these considerations when scheduling pods. We've added native support for taints and tolerations in the Kubernetes executor in GitLab Runner to support these types of workflows.

    - name: "Gitaly support for TLS"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/administration/gitaly/#tls-support"
      reporter: jramsay
      stage: create
      issue_url: "https://gitlab.com/gitlab-org/gitaly/issues/1324"
      description: |
        Gitaly now supports TLS, which means all communication between GitLab
        and Gitaly will be encrypted when TLS is enabled. Previously,
        communication between GitLab and Gitaly was not encrypted, but relied
        on the security of the network.

    - name: "Gitaly support for Elasticsearch"
      available_in: [starter, premium, ultimate]
      gitlab_com: false
      documentation_link: "https://docs.gitlab.com/ee/integration/elasticsearch.html"
      reporter: victorwu
      stage: plan
      issue_url: "https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer/issues/4"
      description: |
        Previously, you had to use NFS to talk to Git in the filesystem if you
        were using Elasticsearch. With this release, you can use Gitaly instead
        of NFS, improving Git access performance.

    - name: "Jump to file in 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_8/mr-fuzzy-finder.png"
      reporter: jramsay
      stage: create
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/53304"
      description: |
        Reviewing large merge requests can be difficult, particularly jumping
        from one file to another. The new fuzzy file finder makes moving from
        one file to another painless, so that you can quickly navigate the diff
        using your keyboard.

    - name: "Approval counts in the merge request list"
      available_in: [starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_approvals.html"
      image_url: "/images/11_8/mr-approval-counts.png"
      reporter: jramsay
      stage: create
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ee/issues/1317"
      description: |
        Merge requests that are approved and ready to merge can now be spotted
        easily from the merge request list. The number of approvals required and
        number of approvals received is now shown in the merge request
        list.

        Thank you [Andy Steele](https://gitlab.com/spacemeld) for the contribution!

    - name: "Receive alerts from manually configured Prometheus instances"
      available_in: [ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#external-prometheus-instances"
      image_url: "/images/11_8/manual-alerts.png"
      reporter: joshlambert
      stage: monitor
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ee/issues/9258"
      description: |
        In GitLab 11.3 support for [setting alerts was introduced](https://about.gitlab.com/blog/2018/09/22/gitlab-11-3-released/#alerts-for-library-metrics), however it was limited to Prometheus instances
        which were deployed through the GitLab [Kubernetes integration](https://docs.gitlab.com/ee/user/project/clusters/#installing-applications).

        With GitLab 11.8, manually configured Prometheus servers can now also notify GitLab of alerts, by simply adding GitLab as a webhook receiver in alertmanager.
        After receiving an alert, GitLab will email Maintainers and Owners of the project.

    - name: "Clean up unused tags from the Container Registry using the API"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/api/container_registry.html#delete-a-repository-tag"
      reporter: joshlambert
      stage: package
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/55978"
      description: |
        Many organizations build containers on every commit, to facilitate validation of code changes, as well as final deployment.
        This can lead to a large number of container tags that are used for a short period of time, and are no longer necessary.

        GitLab 11.8 now allows end users to clean up their container registries using our API, by deleting tags singly or in bulk using a regex.

    - name: "Confidential issues for security vulnerabilities"
      available_in: [ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/merge_requests/#interacting-with-security-reports-ultimate"
      reporter: bikebilly
      stage: secure
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ee/issues/8725"
      description: |
        Users can create a new issue to address and remediate security vulnerabilities
        from the security reports in a merge request, in the pipeline view, and in
        the Security Dashboard. This information contains sensitive data that
        may disclose confidential details that should not be disclosed before a fix
        is available and released.

        Starting with GitLab 11.8, issues created from a vulnerability are marked as
        [confidential](https://docs.gitlab.com/ee/user/project/issues/confidential_issues.html)
        by default, and users can turn the flag off when the information can be disclosed.

    - name: "Force re-deploy when Auto DevOps application secrets are updated"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/topics/autodevops/#environment-variables"
      reporter: danielgruesso
      stage: configure
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/55540"
      description: |
        When you configure an app secret for Auto DevOps using the `K8S_SECRET_` variable syntax,
        a matching Kubernetes secret will be created for your application.

        When these app secrets are updated, Auto DevOps will redeploy your application with the updated
        secrets.

        Thank you [Aaron Walker](https://gitlab.com/walkafwalka) for the contribution!

    - name: "Display cluster environment in serverless function list view"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/clusters/serverless/#deploying-functions"
      reporter: danielgruesso
      stage: configure
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/54986"
      description: |
        The Serverless page has been improved and will now group functions deployed to Knative
        based on the cluster environment they are deployed to.

        In addition, function description is now displayed along with shortcut button to copy
        the function endpoint and another open the endpoint in a new tab.

    - name: "Ensure Cert-Manager works with Auto DevOps URLs"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/topics/autodevops/#auto-devops-base-domain"
      reporter: danielgruesso
      stage: configure
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/55820"
      description: |
        Cert-Manager provides an easy way to add HTTPS support for your
        Auto DevOps applications. This release adds support for URLs longer than
        the default 64 characters supported by Let's Encrypt, providing more
        flexibility for your applications.

    - name: GitLab Runner 11.8
      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.8 today! [GitLab Runner](https://docs.gitlab.com/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 fix for race condition in windows cache extraction](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/863)
        * [Prevent Executors from modifying Runner configuration](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1134)
        * [Add support for fedora/29 packages](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1082)
        * [Update Docker client SDK](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1148)

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

    - name: "Omnibus improvements"
      available_in: [core, starter, premium, ultimate]
      gitlab_com: false
      documentation_link: "https://docs.gitlab.com/omnibus/"
      reporter: joshlambert
      description: |
        - GitLab's [docker-distribution-pruner](https://gitlab.com/gitlab-org/docker-distribution-pruner) is now bundled with Omnibus, allowing administrators a method to clean up registry storage.
        - GitLab 11.8 includes [Mattermost 5.7.1](https://mattermost.com/blog/mattermost-5-7-the-most-secure-way-to-adopt-chatops-performance-improvements-and-more/), an [open source Slack-alternative](https://mattermost.com/) whose newest release includes several user experience improvements. This version also includes [security updates](http://about.mattermost.com/security-updates/) and upgrading is recommended.
        - `node_exporter` no longer runs by default in the Omnibus docker image, as it requires access to the host.
        - Additional alerts have been added, notifying administrators about: high unicorn utilization, sidekiq job queues, postgres deadlocks, high error rates, and more.
        - `nginx` has been updated to 1.12.2, `registry` to 2.7.1, and `gitlab-elasticsearch-indexer` to 1.0.0.
        - `prometheus` has been updated to 2.6.1, `node_exporter` to 0.17.0, and `redis_exporter` to 0.26.0.

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

        In GitLab 11.8, we have significantly improved the performance of
        checking task lists in issues, merge requests, and epics by [not
        re-rendering the entire description after a task is checked or
        unchecked](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23938)

    - name: "GitLab chart improvements"
      available_in: [core, starter, premium, ultimate]
      gitlab_com: false
      documentation_link: "https://docs.gitlab.com/charts/"
      reporter: joshlambert
      description: |
        - GCS is now a [supported bucket type for backups](https://docs.gitlab.com/charts/advanced/external-object-storage/index.html#backups-storage-example)
        - Postgres databases with [mutual TLS authentication](https://docs.gitlab.com/charts/advanced/external-db/index.html#configuring-gitlab-to-use-an-external-database) can now be utilized
        - `ruby` has been updated to 2.5.3

mvp:
  fullname: "Aaron Walker"
  gitlab: walkafwalka
  description: |
    Contributor walkafwalka added two new Auto DevOps features this release, [support for custom domains](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/24248)
    and [redeployment when only secrets have changed](#force-re-deploy-when-auto-devops-application-secrets-are-updated). Thank you for the great improvements!

cover_img:
  image_url: "https://unsplash.com/photos/HIghIy9i0aY"
  licence: Unsplash
  licence_url: "https://unsplash.com/license"

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

deprecations:
  - feature_name: "Ruby 2.5 required"
    due: Dec. 22, 2018
    reporter: stanhu
    description: |
      Beginning with GitLab 11.6, Ruby 2.5 is required to run
      GitLab. [Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/2806)
      and the [GitLab Chart](https://gitlab.com/gitlab-org/build/CNG/merge_requests/195) already ship with Ruby 2.5.3,
      but users of source installations that run Ruby 2.4 will have to upgrade.

  - feature_name: Raspbian Jessie support
    due: Feb. 22, 2019
    reporter: joshlambert
    description: |
      GitLab [11.8](https://gitlab.com/groups/gitlab-org/-/milestones/23) is the last release with support for Raspbian Jessie.

      Jessie has [transitioned to LTS](https://www.debian.org/News/2018/20180601), and the
      [latest Raspbian Jessie image](https://downloads.raspberrypi.org/raspbian/images/raspbian-2017-07-05/) is over a year old.
      We recommend that users upgrade to [Raspbian Stretch](https://www.raspberrypi.org/downloads/raspbian/).

  - feature_name: "Google OAuth2 SSO only supported in GitLab 11.7+"
    due: Mar. 7, 2019
    reporter: jeremy
    description: |
      On Mar. 7, 2019, Google is shutting down all Google+ APIs. You can read
      more about the announcement from Google [here](https://developers.google.com/+/api-shutdown).

      Since GitLab versions prior to [11.7](https://gitlab.com/groups/gitlab-org/-/milestones/22) rely on these APIs for Google OAuth2,
      Google single sign-on will no longer function on these versions. GitLab
      [11.7](https://gitlab.com/groups/gitlab-org/-/milestones/22) and beyond [will support Google SSO](https://gitlab.com/gitlab-org/gitlab-ce/issues/55668).

      If your instance relies on Google OAuth2 for authentication, we recommend
      upgrading to [11.7](https://gitlab.com/groups/gitlab-org/-/milestones/22).

  - feature_name: "Developers can delete Git tags in GitLab 11.9"
    due: Mar. 22, 2019
    reporter: jeremy
    description: |
      Removing or modifying release notes for Git tags on non-protected branches has been historically
      restricted to [Maintainers and Owners](https://docs.gitlab.com/ee/user/permissions.html#project-members-permissions).

      Since Developers can add tags as well as modify and remove non-protected
      branches, Developers should be able to remove Git tags as well.
      In GitLab [11.9](https://gitlab.com/groups/gitlab-org/-/milestones/18), [we're making this change](https://gitlab.com/gitlab-org/gitlab-ce/issues/52954) to our permissions model to improve
      workflow and help developers make better and more effective use of tags.

      If you'd like to continue to restrict this permission to Maintainers and Owners, you can make use of [protected tags](https://docs.gitlab.com/ee/user/project/protected_tags.html#configuring-protected-tags).

  - feature_name: "Hipchat integration"
    due: Mar. 22, 2019
    reporter: victorwu
    description: |
      Hipchat [will be discontinued](https://www.atlassian.com/partnerships/slack/faq#faq-2013ca70-3170-4a82-9886-03234e7084c0). So we
      are [removing the existing GitLab Hipchat integration feature](https://gitlab.com/gitlab-org/gitlab-ce/issues/52424) as part of the [11.9](https://gitlab.com/groups/gitlab-org/-/milestones/18) release.
  
  - feature_name: "CentOS 6 support for GitLab Runner using the Docker executor"
    due: Mar. 22, 2019
    reporter: brendan
    description: |
      Runner support for CentOS 6 when using the Docker executor will be removed in GitLab [11.9](https://gitlab.com/groups/gitlab-org/-/milestones/18) because we are updating to a more current Docker library which no longer supports CentOS 6. Please see [this issue](https://gitlab.com/gitlab-org/gitlab-runner/issues/3905) for additional details.

  - feature_name: "Removal of the System Info section in the admin panel"
    due: Apr. 22, 2019
    reporter: jeremy
    description: |
      GitLab presents information about your GitLab instance at `admin/system_info`, but this information can be inaccurate.

      We're [removing this section](https://gitlab.com/gitlab-org/gitlab-ce/issues/46839) of the admin panel in 11.10, and recommend using [other monitoring capabilities](https://docs.gitlab.com/ee/administration/monitoring/performance/).

  - feature_name: "GitLab.com Pages domains that are not validated will be removed after one week"
    due: Apr. 22, 2019
    reporter: jyavorska
    description: |
      In order to improve performance of GitLab.com, domains that are not able to be
      validated will be deleted after one week (the validation will be tried for four
      days before the one-week countdown starts.) If you are relying on holding the
      domain with GitLab without having done validation, you will now need to complete
      that step in order to ensure that the domain remains registered with you. Please
      see the [instructions on how to
      validate your domain](https://docs.gitlab.com/ee/user/project/pages/getting_started_part_three.html#dns-txt-record) to ensure you do not run into any issues. If your GitLab.com
      Pages domain is not serving 404 errors, then it is already validated.

      See [gitlab-ce#44696](https://gitlab.com/gitlab-org/gitlab-ce/issues/44696) for details on
      the plan for cleanup.

  - feature_name: "Support for Prometheus 1.x in Omnibus GitLab"
    due: Jun. 22, 2019
    reporter: joshlambert
    description: |
      With GitLab [11.4](https://gitlab.com/groups/gitlab-org/-/milestones/19), 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](https://gitlab.com/groups/gitlab-org/-/milestones/33), 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.

  - feature_name: "TLS v1.1 will be disabled by default in 12.0"
    due: Jun. 22, 2019
    reporter: joshlambert
    description: |
      Beginning with GitLab [12.0](https://gitlab.com/groups/gitlab-org/-/milestones/33), [TLS v1.1 will be disabled by default](https://docs.gitlab.com/omnibus/update/gitlab_11_changes.html#tls-v11-deprecation)
      to improve security. This mitigates numerous issues including Heartbleed
      and makes GitLab compliant out of the box with the PCI DSS 3.1 standard.

      To disable TLS v1.1 immediately, set `nginx['ssl_protocols'] = "TLSv1.2"` in
      `gitlab.rb` and run `gitlab-ctl reconfigure`.

  - feature_name: "OpenShift template for installing GitLab"
    due: Jun. 22, 2019
    reporter: joshlambert
    description: |
      The official [`gitlab` helm chart](https://docs.gitlab.com/ee/install/kubernetes/gitlab_chart.html) is the recommended method for
      operating GitLab on Kubernetes, including [deployment on OpenShift](https://gitlab.com/charts/gitlab/blob/master/doc/installation/cloud/openshift.md).

      The [OpenShift template](https://docs.gitlab.com/ee/install/openshift_and_gitlab/index.html)
      for installing GitLab is deprecated, and will no longer be supported in GitLab [12.0](https://gitlab.com/groups/gitlab-org/-/milestones/33).

  - feature_name: "GitLab Geo will enforce Hashed Storage in GitLab 12.0"
    due: Jun. 22, 2019
    reporter: mkozono
    description: |
      GitLab Geo requires [Hashed
      Storage](https://docs.gitlab.com/ee/administration/repository_storage_types.html#hashed-storage)
       to mitigate race conditions on secondary nodes. This was noted in
      [gitlab-ce#40970](https://gitlab.com/gitlab-org/gitlab-ce/issues/40970).

      In [11.5](https://gitlab.com/groups/gitlab-org/-/milestones/20), we added this requirement to the Geo documentation:
      [gitlab-ee#8053](https://gitlab.com/gitlab-org/gitlab-ee/issues/8053).

      With [11.6](https://gitlab.com/groups/gitlab-org/-/milestones/21), `sudo gitlab-rake gitlab:geo:check` checks that Hashed
      Storage is enabled and all projects are migrated:
      [gitlab-ee#8289](https://gitlab.com/gitlab-org/gitlab-ee/issues/8289). If
      you are using Geo, please run this check and migrate as soon as possible.

      In [11.8](https://gitlab.com/groups/gitlab-org/-/milestones/23), a
      permanently dismissable warning will be displayed on the
      "Admin Area › Geo › Nodes" page if the above checks are not resolved:
      [gitlab-ee!8433](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/8433)

      In [12.0](https://gitlab.com/groups/gitlab-org/-/milestones/33), Geo will enforce the Hashed Storage requirement:
      [gitlab-ee#8690](https://gitlab.com/gitlab-org/gitlab-ee/issues/8690).
