features:
# TOP FEATURE
  top:
    - name: "Publish releases for your projects"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/releases/index.html"
      image_url: "/images/11_7/release-releases_page.png"
      reporter: jyavorska
      stage: release
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/41766"
      description: |
        Our new Releases feature adds the ability to create releases in GitLab and view them on a summary page. Releases are
        a snapshot in time of the source, links, and other metadata or artifacts associated with a
        released version of your code, and allow for users of your project to easily discover the latest released
        version of your code.

# PRIMARY FEATURES
  primary:
    - name: "Multi-level Child Epics"
      available_in: [ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/group/epics/"
      image_url: "/images/11_7/child-epics.png"
      reporter: victorwu
      stage: plan
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ee/issues/8333"
      description: |
        Epics and issues work great together to provide flexibility in defining
        longer-term work plans. However, they are still limited to providing
        only a two-layer structure.

        With this release, we are introducing Child Epics. You can now have an
        epic containing both issues and epics. This allows you to create
        multi-level work breakdown structures. So you can now represent even
        longer-term strategic initiatives or organization goals as high-level
        epics, and then have multiple levels of epics below those to break them
        down into more tangible deliverables, all the way down to issues.

    - name: "Cross-project pipeline browsing"
      available_in: [premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/ci/pipelines.html#pipeline-graphs"
      image_url: "/images/11_7/release-pipeline_expansion.png"
      reporter: jyavorska
      stage: verify
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ee/issues/2122"
      description: |
        It is now possible to expand upstream or downstream cross-project pipelines right from the
        pipeline view, giving you visibility into your end-to-end pipelines, no matter in which project
        they start or finish.

    - name: "Remediate vulnerability with patch file"
      available_in: [ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/merge_requests/#solutions-for-dependency-scanning-ultimate"
      image_url: "/images/11_7/auto-patch.png"
      reporter: bikebilly
      stage: secure
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ee/issues/5656"
      description: |
        GitLab can detect different types of vulnerabilities in your apps, and also suggest a possible
        remediation to fix them.

        Starting with GitLab 11.7, you can download a patch file, and apply it to your repo using the
        `git apply` command. Then you can push changes back to your repository, and the [security dashboard](https://docs.gitlab.com/ee/user/project/security_dashboard.html)
        will confirm if the vulnerability is gone!
        This makes the resolution process very easy and reduces the time needed to deploy a solution.
        Currently, Dependency Scanning vulnerabilities for the `yarn` package manager are supported, and
        you don't need to change anything to make it work. The patch will be available, every time it is
        possible, in the vulnerability details window.

    - name: "Configure Kubernetes app secrets as variables for Auto DevOps pipelines"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/topics/autodevops/#application-secret-variables"
      image_url: "/images/11_7/autodevops-secrets.png"
      reporter: danielgruesso
      stage: configure
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/49056"
      description: |
        Operators and administrators require that the configuration of secrets takes place outside the application's repository to
        reduce risk and exposure of sensitive data. To address this need, GitLab now offers the ability to configure
        secrets as environment variables that are made available to the Auto DevOps application running in your Kubernetes cluster.

        Simply prepend your variable with `K8S_SECRET_` and the relevant Auto DevOps CI pipeline will take your application
        secret variable to populate a Kubernetes secret.

    - name: "NPM registry"
      available_in: [premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/packages/npm_registry.html"
      image_url: "/images/11_7/npm_package_view.png"
      reporter: joshlambert
      stage: package
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ee/issues/5934"
      description: |
        JavaScript developers need a secure, standardized way to share and version control NPM packages across projects. An NPM registry offers developers of lower-level services a way to publish their code in such a way.

        In GitLab 11.7, we are proud to offer NPM registries built directly into GitLab. This being integrated right into GitLab would mean they can then share a simple package-naming convention to utilize that library in any Node.js project, and NPM and GitLab will do the rest, all from a single interface. This feature is available with GitLab Premium.

        Check out a [sample project](https://gitlab.com/gitlab-org/examples/npm-publish) which builds and pushes to the GitLab NPM registry, and see how easy it is!

    - name: "API support for Kubernetes integration"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/api/project_clusters.html"
      image_url: "/images/11_7/cluster-api.png"
      reporter: danielgruesso
      stage: configure
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/40473"
      description: |
        With this release, we have brought API support to our Kubernetes integration. This means that all the actions
        currently available in the GUI, such as listing, adding, and deleting a Kubernetes cluster are now accessible
        via the API. Teams can use this new functionality to fold in cluster creation as part of their workflow.

# SECONDARY FEATURES
  secondary:
    - name: "Search filter box for issue board navigation"
      available_in: [starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/issue_board.html#multiple-issue-boards-starter"
      image_url: "/images/11_7/search-filter-issue-board-navigation.png"
      reporter: victorwu
      stage: plan
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ee/issues/7715"
      description: |
        Teams often use many issue boards in a given project or board, making
        the dropdown navigation difficult to use if the list is very long. With
        this release, we are introducing a search filter. Simply type a few characters
        in the search filter box to quickly narrow down to the issue board you are
        interested in, making navigation much easier.

    - name: "Project list redesign"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/"
      image_url: "/images/11_7/project_list.png"
      reporter: jeremy
      stage: manage
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/51944"
      description: |
        Projects are first-class citizens in GitLab, and we want to make project
        lists visually pleasing and easy to parse.

        In GitLab 11.7, we introduced a redesign of the project list UI that focuses
        on readability and a summary of the project's activity. We've given each
        project row additional project information and whitespace, and will
        [continue to iterate](https://gitlab.com/gitlab-org/gitlab-ce/issues/55669)
        on the design based on feedback.

    - name: "Support catch-all email mailboxes including Microsoft Exchange and Google Groups for incoming email features"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/administration/incoming_email.html"
      reporter: victorwu
      stage: plan
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/29951"
      description: |
        GitLab has some great features that use incoming email, such as [reply by email](https://docs.gitlab.com/ee/administration/reply_by_email.html),
        [new issue by email](https://docs.gitlab.com/ee/user/project/issues/create_new_issue.html#new-issue-via-email),
        [new merge request by email](https://docs.gitlab.com/ee/user/project/merge_requests/index.html#create-new-merge-requests-by-email),
        and [service desk](https://docs.gitlab.com/ee/user/project/service_desk.html).
        Previously, you could only take advantage of these features if you used an email
        server configured to use sub-addressing.

        With this release, GitLab now supports both sub-addressing and catch-all
        email mailboxes, using a new email format, allowing more email servers to
        be used with GitLab, including Microsoft Exchange and Google Groups (which
        do not support sub-addressing).

    - name: "Import issues CSV"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/issues/csv_import.html"
      image_url: "/images/11_7/import-issues-csv.png"
      reporter: victorwu
      stage: plan
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/49231"
      description: |
        Often when teams start using GitLab, they may be using different tools and have legacy data.
        You may be currently using Jira but would like to move to GitLab issues.

        With this release, we are making this transition easier. Since many issue
        tracking systems allow for a CSV export, you can now import such an export
        of issues into GitLab, allowing you to continue managing your existing
        work, importing legacy data into GitLab for future search and retrieval
        as necessary. This will work with Jira or any issue tracking system that
        can generate a CSV export.

        GitLab also has an existing [CSV export feature](https://docs.gitlab.com/ee/user/project/issues/csv_export.html)
        too.

    - name: "Short commit SHA available as environment variable"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/ci/variables/#predefined-variables-environment-variables"
      image_url: "/images/11_7/verify-ci_short_commit_sha.png"
      reporter: jyavorska
      stage: verify
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/48061"
      description: |
        Git SHAs are 40-character pointers to specific objects (i.e., commits) in a Git repo. Often, showing the full string
        is unwieldy and you just want to show the first eight characters as a quick (though not guaranteed unique)
        reference. We've added the `CI_COMMIT_SHORT_SHA` environment variable to the CI pipeline for this purpose,
        which will give you the first part of the commit SHA being built.

    - name: "Stricter self-approval restrictions"
      available_in: [starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_approvals.html#eligible-approvers"
      reporter: jramsay
      stage: create
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ee/issues/3845"
      description: |
        Code review is an essential practice of every successful project, and
        should be conducted by someone who isn't the author of the change. By
        default, self approval of merge requests is not permitted, but was
        prevented based on the author of the merge request, not the commits in
        the merge request.

        From GitLab 11.7, self-approval restrictions also prevent people who
        have committed changes to the merge request from approving, so that
        merge requests authored by multiple engineers receive fully independent
        code reviews and approvals.

    - name: "Authorization support for fetching includes"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/ci/yaml/#include"
      reporter: jyavorska
      stage: verify
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/53903"
      description: |
        When including external files in your pipeline definition using the `include` keyword, these are fetched using
        HTTP/HTTPS requests. You are now able to access yamls on another project with no public access (e.g.,
        a private project on GitLab.com) using the credentials the pipeline is running as.

    - name: "Filter vulnerabilities in the Group Security Dashboard"
      available_in: [ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/application_security/security_dashboard/#viewing-the-vulnerabilities"
      image_url: "/images/11_7/dashboard-filters.png"
      reporter: bikebilly
      stage: secure
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ee/issues/6240"
      description: |
        The Group Security Dashboard allows security teams to keep everything under control
        by showing vulnerabilities that affect their groups.

        With GitLab 11.7, users can filter displayed vulnerabilities by severity, report type,
        and project name. With this ability, they can focus on what they need and reach their
        data faster, especially useful when there are many entries in the list.

    - name: "Show Dependency Scanning results in the Group Security Dashboard"
      available_in: [ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/application_security/security_dashboard/#supported-features"
      image_url: "/images/11_7/dependency-scanning-dashboard.png"
      reporter: bikebilly
      stage: secure
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ee/issues/8481"
      description: |
        The Group Security Dashboard was initially released with [SAST](https://docs.gitlab.com/ee/user/application_security/sast/)
        results only, so users were not able to manage other types of vulnerabilities with this feature.

        With GitLab 11.7, [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/)
        findings have been added to the set of available data.
        If you are already using the [new report syntax](https://docs.gitlab.com/ee/ci/yaml/#artifactsreportsdependency_scanning-ultimate),
        you will automatically see results in the dashboard.
        The [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) template has been
        updated as well, and it now requires [GitLab Runner](https://docs.gitlab.com/runner/) 11.5 or above
        to run the Dependency Scanning job correctly.

    - name: "Include CI/CD files from other projects and templates"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/ci/yaml/#include"
      image_url: "/images/11_7/advanced-includes.png"
      reporter: bikebilly
      stage: verify
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/53445"
      description: |
        The `include` keyword allows users to create CI/CD pipelines dynamically, with
        external files included into the configuration. This was previously possible
        only for files in the project repository, or for remote files fetched via HTTP.

        With GitLab 11.7, users can include their snippets of configuration also from
        other projects and from the predefined templates.
        GitLab will include snippets for specific jobs, like `sast` or
        `dependency_scanning`, so users can reference them instead of copying and pasting
        the current definition. The jobs will automatically be updated to the latest
        version when GitLab is updated, so there is no need for manual changes.

    - name: "RBAC mode default for Kubernetes cluster creation"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/clusters/#role-based-access-control-rbac"
      reporter: danielgruesso
      stage: configure
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/53696"
      description: |
        Securing your Kubernetes cluster is vital in order to control and limit who can access the cluster
        and what actions they are allowed to perform.

        Starting with GitLab 11.7, all clusters will default to RBAC-enabled at time of creation, providing more secure and
        protected infrastructure.

    - name: "Support for private Go packages in subgroups"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/group/subgroups/"
      reporter: jramsay
      stage: create
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/45055"
      description: |
        Go packages hosted in GitLab can be installed using `go get`, however
        this was not supported for private projects in subgroups. Starting with
        GitLab 11.7, any project can be used as a Go package, including private
        projects in subgroups.

        Private packages are supported by the `go get` command using a `.netrc`
        file, and using a personal access token in the `password` field.

        Thank you [MortyChoi](https://gitlab.com/mortyccp) for the
        contribution!

    - name: "Support for NGINX Ingress 0.16.0+ metrics"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/integrations/prometheus_library/nginx_ingress.html"
      reporter: joshlambert
      stage: monitor
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/50431"
      description: | # supports markdown
        With the release of [NGINX Ingress 0.16.0](https://github.com/kubernetes/ingress-nginx/blob/master/Changelog.md#0160),
        Prometheus metrics are now [built in natively](https://github.com/kubernetes/ingress-nginx/pull/2608) rather than relying
        on an external exporter.

        GitLab 11.7 now includes [support for the metrics](https://docs.gitlab.com/ee/user/project/integrations/prometheus_library/nginx_ingress.html)
        exported by NGINX Ingress 0.16.0+, and will automatically
        detect and display the throughput, latency, and error rate of deployments.

    - name: "Skip CI builds during git push"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/ci/yaml/#skipping-jobs"
      reporter: brendan
      stage: verify
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/18667"
      description: |
        For commits where users don't want to run the CI/CD pipeline, they were able to add a note to the commit message with `[ci skip]`
        or `[skip ci]`.  However, many users don't want to or can't change their commit messages to contain additional information.

        As of GitLab 11.7, users can use [Git push options](https://git-scm.com/docs/git-push#git-push--oltoptiongt) in Git 2.10 or newer
        when pushing to GitLab to prevent the pipeline run for their push.  Using `git push -o ci.skip` will now achieve the same goal
        without any changes to the commit message.

        Thank you [Jonathon Reinhart](https://gitlab.com/JonathonReinhart) for the
        contribution!

    - name: GitLab Runner 11.7
      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.7 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:

        - [Kill Web Terminal session when build is canceled](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1058)
        - [Fix path separator for CI_PROJECT_DIR in Windows](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1128)

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

# Omnibus and performance (required)

    - name: "Omnibus improvements"
      available_in: [core, starter, premium, ultimate]
      gitlab_com: false
      documentation_link: "https://docs.gitlab.com/omnibus/"
      reporter: pm1 # required
      description: |
        - GitLab 11.7 includes [Mattermost 5.6](https://mattermost.com/blog/mattermost-5-6-interactive-message-dialogs-new-admin-tools-ukrainian-language-support-and-more/), an [open source Slack-alternative](https://mattermost.com/) whose newest release includes interactive message dialogs, new admin tools, Ukrainian language support, and much more.
        - [Enhanced Networking](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html) support is now available for the [official GitLab AMI images](https://docs.gitlab.com/ee/install/aws/#choose-the-ami), allowing for additional instance types to be utilized, as well as increased bandwidth.

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

        In GitLab 11.7, we have significantly improved the performance of
        viewing merge requests by [caching syntax highlighted discussion
        diffs](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23857).

        Other noteworthy performance improvements include:

        - [Improve push performance by skipping pre-commit validations that have passed on other branches](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23984)
        - [Remove redundant counts in snippets search](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23952)
        - [Speed up Open board list when there are assignee lists](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9090)

# MVP
mvp:
  fullname: "MortyChoi"
  gitlab: mortyccp
  description: |
    MortyChoi added [support for private Go packages in subgroups](#support-for-private-go-packages-in-subgroups). Thank you for
    making a contribution to help further support this popular language inside GitLab!

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

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

# UPGRADE BAROMETER
barometer:
  reporter: victorwu
  description: | # example (supports markdown)
    To upgrade to GitLab 11.7 from the latest 11.6 version, no downtime is required. Consult [the documentation on upgrades without downtime](https://docs.gitlab.com/ee/update/README.html#upgrading-without-downtime).

    Database migrations in this release may take between 30 and 60 minutes for
    instances similar to the size of GitLab.com. For smaller instances, the
    total time should be no more than roughly 15 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: "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 already ships with Ruby 2.5.3](https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/2806),
      but users of source installations that run Ruby 2.4 will have to upgrade.

  - feature_name: Debian 7 Wheezy support
    due: Dec. 22, 2019
    reporter: joshlambert
    description: |
      GitLab 11.6 was the last release with support for Debian 7 Wheezy. Deprecation was originally announced in
      [GitLab 10.6](https://about.gitlab.com/blog/2018/04/22/gitlab-10-7-released/#debian-7-wheezy-support).

      Debian Wheezy is no longer supported by the Debian project
      [as of May 2018](https://www.debian.org/releases/wheezy/), we strongly recommend users to upgrade to
      [Stretch](https://wiki.debian.org/DebianStretch) or [Jessie](https://wiki.debian.org/DebianJessie).

  - feature_name: Raspbian Jessie support
    due: Feb. 22, 2019
    reporter: joshlambert
    description: |
      GitLab [11.8](https://gitlab.com/groups/gitlab-org/-/milestones/23) will be 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: CentOS 6 support for GitLab Runner using the Docker executor
    due: Mar. 22, 2019
    reporter: jyavorska
    description: |
      GitLab [11.9](https://gitlab.com/groups/gitlab-org/-/milestones/18)
      will be the last release with Runner support for CentOS 6 when using
      the Docker executor because we are planning to update to a more current
      Docker library which no longer supports it. Please see [this
      issue](https://gitlab.com/gitlab-org/gitlab-runner/issues/3905) for
      additional details.

  - 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/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
      [gitlab-ee!8433](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/8433)
      will be displayed on the "Admin Area › Geo › Nodes" page if the above
      checks are not resolved.

      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).

  - 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: |
      Editing/deleting 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 modify and 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.

  - 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.
