features:
# TOP FEATURE
  top:
    - name: Auto DevOps Generally Available
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/topics/autodevops/'
      documentation_text: "See the documentation on Auto DevOps"
      image_url: '/images/11_0/auto-devops.png'
      reporter: danielgruesso
      issue_url: https://gitlab.com/gitlab-org/gitlab-ce/issues/38366
      description: |
        Originally introduced in beta in [GitLab 10.0](/blog/2017/09/22/gitlab-10-0-released/#auto-devops), Auto DevOps is now Generally Available (GA) in GitLab 11.0.
        Auto DevOps provides a complete workflow for your project with minimal configuration, efficiently taking your
        application from the build stage through the production and monitoring stage.

        Auto DevOps brings DevOps best practices to your project by automatically configuring your build, test, Code
        Quality, Static and Dynamic Security Testing, Dependency Scanning, License Management, Container Scanning, Review
        Apps, Browser Performance Testing, deployment, and monitoring in a single application. It makes it easy for
        teams adopting DevOps to start with a complete, holistic pipeline.

        Auto DevOps enables developers to focus on what matters most to the organization – shipping code that brings
        value to their customers.

        [Check out our revamped quick start guide.](https://docs.gitlab.com/ee/topics/autodevops/quick_start_guide.html)

# PRIMARY FEATURES
  primary:
    - name: 'CI/CD pipeline status and job traces in the Web IDE'
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/web_ide/#view-ci-job-logs'
      documentation_text: "See the documentation on Web IDE"
      image_url: '/images/11_0/web_ide_ci_trace.png'
      reporter: jramsay
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/46245'
      description: |
        Continuous integration is an important step in shipping high-quality
        software, and you can now check the CI status of the current commit
        at a glance by checking the status bar at the bottom left of the Web IDE. Even
        better, you can view the status of each job and the logs for each job
        on the right. This makes it easy to fix a merge request with CI
        failures by opening the failed job side by side with the file you're
        working on.

        Previously, fixing failed tests involved opening multiple tabs and
        switching backwards and forwards. Now, all the information you need
        can be opened right in the Web IDE, and
        [in the future](/direction/product-vision/#web-ide)
        you'll be able to preview and test your changes before you commit them.

    - name: Switch between merge requests in the Web IDE
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/web_ide/#switching-merge-requests'
      documentation_text: "See the documentation on Web IDE"
      image_url: '/images/11_0/web_ide_switch_mr.png'
      reporter: jramsay
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/45184'
      description: |
        It's common to end up working on multiple merge requests across multiple
        projects, and it now only takes one click to switch among your
        assigned and authored merge requests. Whether you are reviewing others' merge
        requests, or trying to get your own over the line, the new
        merge request switcher allows you to spend more time coding and
        less time searching.

    - name: License Management
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/application_security/license_compliance/'
      documentation_text: 'See the documentation on License Management'
      image_url: '/images/11_0/license_management.png'
      reporter: bikebilly
      team: Security Products
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/5487'
      description: |
        In modern software development, most applications rely on external components
        to implement specific functions, preventing the need to code everything from scratch every
        time. This is why third-party libraries are so common, and fetched directly by package
        management tools like RubyGems or npm. However, this approach requires you to ensure
        that the licenses for external components are compatible with your
        application, and that there is no conflict that could lead to legal issues.

        In GitLab 11.0, we are proud to introduce License Management as part of our
        integrated development workflow. It automatically collects all the licenses
        used by your dependencies and displays new ones in the Merge Request widget
        before they land on your main default branch.

        If you are using [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/),
        License Management is
        automatically enabled for your projects. Otherwise, you can
        [manually enable it](https://docs.gitlab.com/ee/user/application_security/license_compliance/)
        for your custom `.gitlab-ci.yml` definitions.

    - name: SAML single sign-on for Groups (Beta)
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/group/saml_sso/'
      documentation_text: "See the documentation on SAML for Groups"
      image_url: '/images/11_0/group-saml.png'
      reporter: jeremy_
      epic_url: 'https://gitlab.com/groups/gitlab-org/-/epics/40'
      description: |
        Being able to manage user credentials at scale is a must for large
        organizations. Centralizing users on a company-controlled identity
        provider is a common solution, and we have expanded our support for
        authentication based on Security Assertion Markup Language (SAML) by
        adding it to Groups.

        Group owners are now able to configure an identity provider and
        provide a single sign-on (SSO) link to users. By authorizing them
        through the provided URL, groups can provide managed authentication
        when instance-wide SAML is either unfeasible or not specific enough
        for the group.

        This is especially important for groups on GitLab.com, which can now
        configure identity providers for enterprise use.

    - name: New navigation themes
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/profile/preferences.html'
      documentation_text: "See the documentation on Profile preferences"
      image_url: '/images/11_0/new-navigation-themes.png'
      reporter: akaemmerle
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/43597'
      description: | # supports markdown
        In the last major release, we unveiled [GitLab’s new navigation](/blog/2017/09/13/unveiling-gitlabs-new-navigation/).
        With GitLab 11.0, we think it’s a good time to introduce an additional set of new navigation
        themes! Five new user interface themes provide you with even more options to personalize your
        GitLab experience.

        Besides a fresh red theme, each theme received an additional light counterpart, allowing
        you to make a bold color statement!

# SECONDARY FEATURES
  secondary:
    - name: Squash and Merge in GitLab Core and GitLab.com Free
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/merge_requests/squash_and_merge.html'
      documentation_text: "See the documentation on Squash and merge"
      image_url: '/images/11_0/squash-and-merge-core.png'
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/34591'
      description: |
        When working on a large feature, developers often push multiple commits to a work-in-progress
        branch, and after code review, there may be even more commits to address various code
        issues. Before merging that branch to master, many teams
        prefer to squash all the commits into a single one, ensuring a [clean Git history](/blog/2018/06/07/keeping-git-commit-history-clean/),
        making it easier for folks in the future to review previous code changes.

        Squashing is a Git feature and a developer can do it right before merging on their local
        machine, but with squash and merge available directly in the GitLab web UI, you can
        do it with just a single click. For example, a repo maintainer merging-in the code
        can now do the squash without asking the code contributor to do so,
        saving one extra round-trip communication step.

        Squash and Merge, previously available in GitLab Starter, GitLab.com
        Bronze, and higher tiers, is now open source and available in GitLab Core
        and GitLab.com Free!
        Many users have said that all teams would benefit from this feature, and we are happy
        to bring it to everyone.

        Thank you [blackst0ne](https://gitlab.com/blackst0ne) for your contribution!

    - name: Open projects in Xcode
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/repository/index.html#open-in-xcode'
      documentation_text: "See the documentation on opening in Xcode"
      image_url: '/images/11_0/open_in_xcode.png'
      reporter: jramsay
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/45820'
      description: |
        At WWDC earlier this month,
        [Apple announced their Xcode integration with GitLab](/blog/2018/06/06/one-click-clone-to-xcode/),
        which makes it easier to work with your Xcode projects hosted in
        GitLab.

        <div class="center">
        <blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">Apple just announced Xcode 10 is now integrated with GitLab <a href="https://t.co/eQbtiY4IYm">pic.twitter.com/eQbtiY4IYm</a></p>&mdash; GitLab (@gitlab) <a href="https://twitter.com/gitlab/status/1003764673454342144?ref_src=twsrc%5Etfw">June 4, 2018</a></blockquote>
        <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
        </div>

        Projects that contain a `.xcodeproj` or `.xcworkspace` file can
        now be cloned in Xcode using the new Open in Xcode button in GitLab.
        When viewing Xcode projects in the GitLab interface, the button will be
        available in GitLab next to the Git URL for cloning your project.

    - name: Roadmap date ranges
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/group/roadmap/#timeline-duration'
      documentation_text: "See the documentation on Roadmap date ranges"
      image_url: '/images/11_0/date-ranges.png'
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/4936'
      description: |
        Since epics can take on any start and end dates, we wanted to provide a simple way for users
        to quickly view the ones that are more relevant in a given time range.

        With this release, we are introducing Roadmap date ranges. You can now quickly click Quarters, Months, or
        Weeks, and immediately, the roadmap will be refreshed, enabling you see your epics from different
        time perspectives. Teams who are focused on shipping features in the next few weeks can use one
        granularity, while executive leadership folks who want a high-level overview can use the longer
        time-period views.

    - name: Unlimited Guests for free in Ultimate
      available_in: [ultimate]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/ee/user/permissions.html'
      documentation_text: "See the documentation on guest permissions"
      reporter: jeremy_
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/5693'
      description: |
        In order to help customers get the most from their GitLab instances, Guest
        users no longer count against seat count for Ultimate licenses.

        Since these users no longer consume seats (they're effectively free to
        add), it gives more users in an organization the chance to join the
        instance and contribute to the conversation. You're free to promote
        these users, but they'll count against your license's seat count once
        they're promoted beyond Guest in any project or group.

        This also means that if a user logs in and is never added to a project/group,
        they have no role applied, therefore they are considered as 'Guests.'

    - name: Issue Board assignee lists
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/issue_board.html#assignee-lists'
      documentation_text: "See the documentation on Issue Board assignee lists"
      image_url: '/images/11_0/issue-board-assignee-lists.png'
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/5784'
      description: |
        Issue boards are a great tool for managing and tracking workflows, as your issues progress through different stages in
        your lifecycle, with label lists representing those stages.

        With this release, we are introducing assignee lists to issue boards. An assignee list shows issues that are assigned
        to a specific user. This provides a whole new way to use issue boards: to view and manage issue assignments for your
        team.

        You can now [configure a board](https://docs.gitlab.com/ee/user/project/issue_board.html#configurable-issue-board)
        to a scope that matches that of your team, and then add assignee lists representing team members. This gives you instant
        visibility into what issues your team is working on, whether you are a manager who wants an overview and status of the team's
        overall responsibilities, or an individual contributor who wants to sync up with another team member's assigned issues.

        You can even add label lists and assignee lists to the same board.

    - name: Assign ancestor group milestones
      available_in: [core, starter, premium, ultimate] # required
      documentation_link: 'https://docs.gitlab.com/ee/user/project/milestones/'
      documentation_text: "See the documentation on Milestones"
      image_url: '/images/11_0/assign-ancestor-group-milestones.jpg'
      image_noshadow: true
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/36862'
      description: |
        GitLab supports subgroups, and we have now leveraged that subgrouping structure for milestones. For any issue
        or merge request, you can now assign it a project milestone or a group milestone inherited from _any_ ancestor group.

        In particular, you can now have a high-level group with a set of milestones at that level.
        You can then use those _same_ milestones in any issues and merge requests in any subgroups deeper down, providing a powerful
        and flexible mechanism to organize work if you have nested groups and projects.

        Furthermore, you can filter by this milestone in group issue lists and group issue boards, so that you can pull
        in targeted objects from different levels in customized views.

    - name: Issues and merge requests from subgroups in API
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/api/README.html'
      documentation_text: "See the documentation on GitLab APIs"
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/45082'
      description: |
        Subgroup support is also now consistent in the API when it comes to retrieving [issues](https://docs.gitlab.com/ee/api/issues.html#list-group-issues) and
        [merge requests](https://docs.gitlab.com/ee/api/merge_requests.html#list-group-merge-requests). That is,
        if you query a particular group through the API for issues and merge requests, you will get results
        from projects that are immediate children of that group, and also all from projects of all subgroups nesting down further.
        This is analogous to viewing the same objects in the web UI's group list views, which was introduced in recent prior releases.

    - name: Persistent Auto DevOps deploy tokens for Kubernetes
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/topics/autodevops/#auto-deploy'
      documentation_text: "See the documentation on deploy tokens for Auto DevOps"
      reporter: danielgruesso
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/46075'
      description: |
        Previously, when Auto DevOps was used for private or internal projects, the registry was
        not accessible by Kubernetes after the deploy job completed. This prevented
        the cluster from fetching the image again (for scaling, failures, etc).

        With GitLab 11.0, a new deploy token is created to provide persistent access
        to the registry when Auto DevOps is enabled on private/internal projects.
        This will ensure that the cluster can perform necessary operations and
        reduce possible failures.

    - name: Specify deployment strategy from Auto DevOps settings
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/topics/autodevops/#auto-deploy'
      documentation_text: "See the documentation on Auto DevOps deployments"
      image_url: '/images/11_0/autodevops-deploy-strategy.png'
      reporter: danielgruesso
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/38542'
      description: |
        While some applications may benefit from deploying every change into
        production immediately after it's done, others may fare better by grouping
        those changes into a common environment for more thorough testing.
        Configuring different deployment strategies for different projects
        previously meant dealing with project-specific variables and then
        exercising them as needed.

        Starting in GitLab 11.0, Auto DevOps makes specifying your deployment
        strategy a single-click event. When enabling Auto DevOps for a specific
        project, you will be able to specify whether your application gets
        automatically deployed to production or deployed automatically to
        staging and then manually to production. This single-click configuration
        will allow you to spend more time working on your apps and less time
        configuring their deployment.

    - name: Variables defining deployment policy for canary environments
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/topics/autodevops/#deploy-policy-for-canary-environments'
      documentation_text: "See the documentation on the deployment policy for canary environments"
      reporter: danielgruesso
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/38550'
      description: |
        Oftentimes we'd like to roll out changes to a subset of users or servers to
        evaluate its impact before deploying across an entire environment. Previously,
        Auto DevOps users had to make the Auto DevOps template explicit and then
        define the desired behavior in order to achieve canary deployments.

        Starting with GitLab 11.0, users are able to define their canary policy
        by making use of the `CANARY_ENABLED` environment variable without the need to
        customize the Auto DevOps template, enabling faster canary policy
        declaration.

    - name: Always-on approvals
      available_in: [starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_approvals.html'
      documentation_text: "See the documentation on Merge request approvals"
      image_url: '/images/11_0/always-on-approvals.png'
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/2452'
      description: |
        Merge request approvals are a longstanding GitLab feature that allows teams to enforce code review
        (or any type of review) in a merge request, before unblocking it for merging.

        Prior to this release, the feature had to be configured in the project settings. To simplify and
        streamline the feature, approvals are now always on for all projects in GitLab (in Starter, Bronze, or higher tiers).
        At the same time, however, we definitely do not want to slow down creating and merging code. So when a user
        creates a project, the required number of approvals is by default zero for the project (essentially, the
        feature is "off"). As the project grows, the user (and their team) can naturally adopt approvals by raising
        that required number as appropriate to their workflow needs.
        
    - name: Unmergeable merge request notifications and todos
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/profile/notifications.html'
      documentation_text: "See the documentation on Notifications"
      image_url: '/images/11_0/unmergeable-merge-request.png'
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18042/'
      description: |
        Developers often work on multiple merge requests at a time, and it can be a challenge to keep track of them
        when many are open at once, awaiting collaborator reviews and feedback. Sometimes
        a merge request becomes unmergeable because of a conflict, perhaps caused by a change on the target branch.
        As a result, when you return to work on the merge request, you need to resolve the conflict.
        
        With this release, GitLab can now send you a [notification](https://docs.gitlab.com/ee/user/profile/notifications.html) and even 
        assign you a [todo](https://docs.gitlab.com/ee/user/todos.html) if your
        merge request becomes unmergeable. You'll receive these as long as you are the author of the
        merge request, or have set it to be merged once the pipeline succeeds. This allows you to be
        proactive in fixing conflicts, or at least know what to expect when you revisit a merge request that
        you had worked on previously.

        **Note:** We originally missed mentioning this feature when this blog post was first published. This section has been added as of August 3, 2018.

    - name: Fetch cluster parameters from GKE
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/clusters/#adding-and-creating-a-new-gke-cluster-via-gitlab'
      documentation_text: "See the documentation on Adding and creating a new GKE cluster via GitLab"
      image_url: '/images/11_0/fetch-gke-parameters.png'
      reporter: danielgruesso
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/38759'
      description: |
        Creating Kubernetes clusters in GitLab has never been easier. With GitLab 11.0,
        the "project" and "zones" values are automatically fetched from your Google
        Kubernetes Engine (GKE) account and displayed as a list for easy selection.
        Previously, creating a cluster using our GKE integration meant having to manually
        enter this data.

        Simple cluster creation will allow you to quickly stand up clusters from GitLab
        and quickly deploy your apps.

    - name: Disable Auto DevOps jobs with variables
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/topics/autodevops/#environment-variables'
      documentation_text: "See the documentation on Auto DevOps environment variables"
      reporter: danielgruesso
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/3586'
      description: |
        When your application doesn't precisely fit one or more Auto DevOps stages, such as unit testing, code quality, etc., it is ideal to customize the pipeline to run only the jobs you care about.

        GitLab 11.0 now provides the ability to disable one or more Auto DevOps jobs through the use of environment variables. This allows you to take advantage of the power of Auto DevOps, even when your application doesn't fit with one of its stages.

    - name: LFS files included when importing a project
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/import/index.html'
      documentation_text: "See the documentation on importing projects"
      reporter: jramsay
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/40401'
      description: |
        [Git LFS](https://docs.gitlab.com/ee/administration/lfs/manage_large_binaries_with_git_lfs.html)
        helps to version large files with Git by storing them outside the
        repository and lazily downloading files at checkout rather than clone.

        When importing a project from GitHub, Bitbucket Cloud, or using a Git URL,
        GitLab now imports LFS objects so that you have a complete copy of the
        repository including those LFS objects. Previously, LFS objects were excluded
        from imports.

    - name: Operations tab
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/ci/' # Always use EE docs
      documentation_text: 'See the documentation on GitLab CI'
      image_url: '/images/11_0/operations_tab.jpg'
      image_noshadow: true
      reporter: joshlambert
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/43673'
      description: |
        With the release of GitLab 11.0 we have added an **Operations** section in the navigation sidebar, making it quicker to access and easier to
        discover our operations features. In this release **Environments** and **Kubernetes** have been moved from **CI/CD** to **Operations**,  and we will continue
        to add sections for features like Metrics and Logs in upcoming releases.

    - name: SAST for .NET and Scala
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks'
      documentation_text: 'See the documentation on SAST'
      reporter: bikebilly
      team: Security Products
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/4824'
      issue_2: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/5250'
      description: |
        As part of our effort to increase the availability of our security tools to the most common
        languages and frameworks, we have been continuously iterating on Static Application Security Testing (SAST).

        In GitLab 11.0, we add support for two new languages, .NET and Scala. Users don't need to
        change anything in their projects if they are already using Auto DevOps or the latest
        version of the `sast` job definition in their `.gitlab-ci.yml` file.

    - name: Cloud-native GitLab Helm chart now Beta
      available_in: [core, starter, premium, ultimate]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/ee/install/kubernetes/gitlab_chart.html'
      documentation_text: "See the documentation on GitLab Helm chart"
      reporter: joshlambert
      epic_url: 'https://gitlab.com/groups/charts/-/epics/17'
      description: |
        We are excited to announce that the cloud-native GitLab
        [Helm](https://helm.sh) chart is now in beta. 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.

    - name: Easily deploy and integrate JupyterHub with GitLab
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/clusters/#installing-applications'
      documentation_text: "See the documentation on deploying JupyterHub"
      image_url: '/images/11_0/jupyterhub.png'
      reporter: joshlambert
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/46487'
      description: |
        [JupyterHub](https://jupyterhub.readthedocs.io/en/stable/) is a multi-user
        service for easily launching [notebooks](https://jupyter-notebook.readthedocs.io/en/latest/)
        across a data science team.
        Jupyter notebooks provide a web-based interactive programming environment commonly
        used for data analysis, simulation, visualization, and machine learning.

        GitLab 11.0 can now deploy JupyterHub to an integrated Kubernetes cluster
        with a single click, and it is automatically configured to use GitLab
        for seamless authentication. Additional options like [HTTPS](https://gitlab.com/gitlab-org/gitlab-ce/issues/47137),
        [group filtering](https://gitlab.com/gitlab-org/gitlab-ce/issues/47820), and [custom notebooks](https://gitlab.com/gitlab-org/gitlab-ce/issues/48236)
        will be added in future releases.

    - name: Expanded Issue Weight values
      available_in: [starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/issues/issue_weight.html'
      documentation_text: "See the documentation on Issue Weights"
      image_url: '/images/11_0/expanded-issue-weight-values.jpg'
      image_noshadow: true
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/3969'
      description: |
        Issue weights in GitLab are useful for assigning effort estimation or any other cost metric
        associated with working on an issue. Previously, you could only assign values 1 through 9
        for an issue. But this meant that teams that wanted more granularity in their weighting were constrained.

        Starting in this release, issue weights can take on any non-negative integer value, from 0 upward, giving you
        unlimited flexibility in how you use weights. Furthermore, [Burndown Charts](https://docs.gitlab.com/ee/user/project/milestones/burndown_charts.html)
        automatically consider these new weight values, so your team can immediately make use of an expanded range.

    - name: Combined system note for successive issue description updates
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/issues/'
      documentation_text: "See the documentation on Issues"
      image_url: '/images/11_0/combined-system-note.png'
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/33166'
      description: |
        GitLab allows for powerful asynchronous collaboration and communication. With the ability
        to document ideas and have conversations in so many places, we encourage always maintaining
        a single source of truth in the description area of an issue or epic.

        This means that descriptions are often updated, many times in succession over a few minutes,
        leading to multiple system notes that say that the description has been updated. With this release,
        we are smartly combining those system notes if they happen within a short period of time,
        cleaning up the visual clutter and making comments in GitLab just a little bit easier to navigate. We'll
        be adding the same functionality to merge requests in the next release.

    - name: View Kubernetes pod logs
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/clusters/kubernetes_pod_logs.html'
      documentation_text: 'See the documentation on Pod Logs'
      image_url: '/images/11_0/pod_logs.png'
      reporter: joshlambert
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/4752'
      description: |
        A fundamental need for all developers is to be able to review logs in order
        to understand application behavior and troubleshoot any problems
        that arise. With GitLab 11.0,
        reviewing the logs of a troublesome pod is now just a click away.

        On the **Environments** page, the status of pods for each application is
        displayed using [Deploy Boards](https://docs.gitlab.com/ee/user/project/deploy_boards.html).
        Mousing over the pods will display the full pod name and status,
        and clicking on the pod will then display the logs.

    - name: Master role renamed to Maintainer
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/permissions.html'
      documentation_text: "See the documentation on Permissions"
      image_url: '/images/11_0/master-to-maintainer.jpg'
      image_noshadow: true
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/42751'
      description: |
        At GitLab, we are [striving to build an inclusive culture](https://about.gitlab.com/handbook/values/#diversity--inclusion).
        And so even within GitLab the product, we're seeking ways to reflect that.

        We've decided to rename the Master role to the Maintainer role. It removes the negative connotations
        that may be associated with the term "Master," and at the same time, "Maintainer" is easily understood. Every
        small step helps, and we hope to move forward at GitLab, and together as an industry.

    - name: Label lists redesign
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/labels.html'
      documentation_text: 'See the documentation on Labels'
      image_url: '/images/11_0/label-list-redesign.png'
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/39549'
      description: |
        Labels are a powerful mechanism in GitLab. As teams continue to create and use more labels,
        we want to ensure that managing them is easy. In this release, we've cleaned up the design
        of the label list pages, simplifying the interface, making it easier to consume information at
        a glance, and providing the UI affordances to quickly manage a particular label in further detail.

    - name: Consistent naming format in issues API scope attribute
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/api/issues.html'
      documentation_text: "See the documentation on Issues API"
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/44799'
      description: |
        We made a small change in the issues API scope attribute to bring it in line with our consistent
        format of using snake case. The scope attribute now uses the values of `created_by_me` and `assigned_to_me`.
        You should use this format starting in GitLab 11.0 instead of the previous kebab-case (hyphenated) equivalents.

    - name: Regex support for variables expressions
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/ci/variables/#variables-expressions'
      documentation_text: "See the documentation on regex support for variables expressions"
      image_url: '/images/11_0/regex_variables.png'
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/43601'
      description: |
        In GitLab 10.7, we added support for variables expressions to `only` and `except` keywords.
        This allowed to define if a job should be created if a variable existed or had a specific value.

        With GitLab 11.0, we are extending this syntax to allow regex. Now you can create more flexible
        definitions based on a fine-grained pattern matching against the value. For example, you can skip
        a job based on the commit message.

    - name: Get GitLab Runner IP address via the API
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/api/runners.html#get-runner-s-details'
      documentation_text: 'See the documentation on GitLab Runner APIs'
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/46102'
      description: |
        In GitLab 10.6 we added the ability to see the IP address of a given GitLab Runner
        in the details view in the UI. This is very useful to better recognize, troubleshoot,
        and manage your infrastructure.

        With GitLab 11.0, we also expose this information in the API response so that it can
        be used by automated processes.

        Thank you [Lars Greiss](https://gitlab.com/lgreiss) for your contribution!

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

        ##### Key changes in this release include:

        * [Add `--paused` option to register command](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/896)
        * [Change Prometheus metrics names](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/912)
        * [Start rename of "metrics server" config](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/838)
        * [Rename CI_COMMIT_REF to CI_COMMIT_SHA](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/911)

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

    - name: Improved deprecated configuration detection
      available_in: [core, starter, premium, ultimate]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/omnibus/README.html'
      documentation_text: "See the documentation on Omnibus GitLab"
      reporter: joshlambert
      mr_url: 'https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/2527'
      description: |
        Starting from GitLab 11.0, the Omnibus GitLab package will check for deprecated configuration in `gitlab.rb`, prior to starting an upgrade. In the event deprecated configuration settings are found,
        the package will abort the upgrade process prior to any changes. This allows the existing version to continue to run, while an administrator updates the problematic settings.

    - name: Geo improvements
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/administration/geo/replication/configuration.html'
      documentation_text: "See the documentation on Geo"
      reporter: akaemmerle
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/45820'
      description: |
        We continously improve our Geo feature for distributed teams. Some of the noteworthy improvements in GitLab 11.0 include:

        * [`git fetch` and `git push` operations on secondary Geo nodes are now automatically redirected to the primary node when using HTTP](https://gitlab.com/gitlab-org/gitlab-ee/issues/3912)
        * [New rake tasks allow to schedule housekeeping on following repository synchronizations](https://gitlab.com/gitlab-org/gitlab-ee/issues/5928)
        * [Geo command that runs `git fsck` is now written in Go for a performance improvement](https://gitlab.com/gitlab-org/gitaly/issues/1175)
        * [When using hashed storage, the GitLab Shell log file now displays the readable repository name](https://gitlab.com/gitlab-org/gitlab-ce/issues/41229)

    - name: Project-specific pipeline ID
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/ci/variables/#predefined-variables-environment-variables'
      documentation_text: "See the documentation on predefined CI/CD variables"
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/3691'
      description: |
        When running CI/CD jobs for your project, sometimes you need a way to differentiate one execution
        from another. For this scope, you need a unique identifier that changes every time a new pipeline
        is created. This feature was already available through the `CI_PIPELINE_ID` environment variable,
        but this counter is unique for the entire GitLab instance and so it grows very fast, creating
        possible problems with long numbers.

        In GitLab 11.0 we are introducing another environment variable, `CI_PIPELINE_IID`, that contains
        a reference that is specific to the project. It means that it is incremented only when another
        run for the same project is created, keeping the value low and allowing developers to use it as
        part of the release process, for example as part of the version number.

# Omnibus and performance (required)

    - name: Omnibus improvements
      available_in: [core, starter, premium, ultimate]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/omnibus/'
      documentation_text: 'See the documentation on Omnibus GitLab'
      reporter: joshlambert
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/12345'
      description: |
        - GitLab 11.0 includes [Mattermost 4.10](https://about.mattermost.com/releases/mattermost-4-10/), an [open source Slack-alternative](https://about.mattermost.com/) whose newest release includes Environment Variables Support in GitLab Omnibus, faster load times, ability to convert channels to private, plus much more.
        - Added a new flag, `master_on_initialization`, to control if a database node should report it itself as master. This flag should be disabled on secondaries.
        - Prometheus [rules can now be configured](https://docs.gitlab.com/omnibus/settings/prometheus.html#rules-files), providing the ability to add your own recording or alerting rules to the embedded Prometheus server.
        - The [PgBouncer exporter](https://docs.gitlab.com/ee/administration/monitoring/prometheus/pgbouncer_exporter.html) has now been added, providing insight into its health and operation.
        - `ruby` has been updated to 2.4.4. `git` has been updated to 2.17.1. `libpcre` has been updated to 10.31. `PgBouncer` has been updated to 1.8.1.
        - Let's Encrypt support has been added for the [Registry](https://docs.gitlab.com/omnibus/settings/ssl.html#registry) and [Mattermost](https://docs.gitlab.com/omnibus/settings/ssl.html#mattermost). When new certificates are requested, these hostnames will be added to the certificate.

    - 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.0
      documentation_text: See all the performance improvements in GitLab 11.0
      reporter: various
      description: |
        Some of the more noteworthy performance improvements in GitLab 11.0
        include:

        * [Searching issues within a group no longer times out on GitLab.com](https://gitlab.com/gitlab-org/gitlab-ce/issues/46648)
        * [Merge requests make fewer calls to access repository data](https://gitlab.com/gitlab-org/gitlab-ce/issues/45190)
        * [Notification emails run dramatically fewer SQL queries to calculate the recipients](https://gitlab.com/gitlab-org/gitlab-ce/issues/45534)
        * [Viewing a group page on GitLab.com no longer runs a query per subgroup to check access to Epics](https://gitlab.com/gitlab-org/gitlab-ee/issues/6206)
        * [The LFS integrity check that takes place when pushing into a project that uses LFS is improved](https://gitlab.com/gitlab-org/gitlab-ce/issues/45062)
        * [Loading the projects API no longer preloads all of the authenticated user's membership records](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18945)
        * [Viewing a group page uses fewer queries to find projects, and a faster query to determine the open MR count](https://gitlab.com/gitlab-org/gitlab-ce/issues/43048)
        * [Deleting a group using the API now takes place in the background](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/5505)
        * Many of the most commonly used APIs load significantly faster because of better preloading: [issues API](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/19345), [issues API again](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/19269), [merge requests API](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/19346), [events API](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/19347), [jobs API](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/19353)
        * [Displaying a project's pipelines now requires fewer SQL queries](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18427)
        * We [upgraded Bootstrap 3 to 4](https://gitlab.com/gitlab-org/gitlab-ce/issues/45185) in preparation for our [GitLab UI Framework](https://gitlab.com/groups/gitlab-org/frontend/-/epics/1)

# MVP
mvp:
  fullname: "Vitaliy 'blackst0ne' Klachkov"
  gitlab: blackst0ne
  description: |
    Vitaliy has contributed many times to GitLab, and has already been the release
    MVP a couple of times this year.
    For GitLab 11.0, he handled a large amount of technical debt by converting
    most of our remaining Spinach tests to RSpec and relentlessly
    working to fix GitLab for Rails 5. Also, once we decided to
    bring the Squash and Merge feature into GitLab Core and GitLab.com free,
    Vitaliy took on the issue and made it happen for this release.
    Here are all the [improvements he submitted to GitLab 11.0](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=11.0&label_name[]=Community%20Contribution&author_username=blackst0ne).

    Vitaliy, you rock! Thanks again! 🙌 You'll receive a brand new swag pack soon!

# COVER IMAGE LICENCE
cover_img:
  image_url: 'https://www.istockphoto.com/foto/mount-cook-and-lake-matheson-new-zealand-with-milky-way-gm691684632-128101367'
  licence: iStock license (purchased image)
  licence_url: 'https://www.istockphoto.com/help/licenses'

# CTA
cta:
  - title: Join us for an upcoming event
    link: /events/
  - title: "11.0 Release Radar webcast"
    link: 'https://youtu.be/6LZQCCVGVDg'

# UPGRADE BAROMETER
barometer:
  reporter: mayra_cabrera
  description: |
    In order to ensure successful upgrades to GitLab 11.0, the current version
    must be 10.8 or above. The GitLab 10.8 package
    [includes additional checks for deprecated settings](/blog/2018/05/22/gitlab-10-8-released/#omnibus-improvements),
    and will abort the upgrade in the event any are found.

    Previously it was possible to upgrade with settings that are no
    longer supported, causing the GitLab service to be unable to start.

    You can upgrade to GitLab 11.0 from 10.8 or above without any downtime. See the
    [documentation on downtimeless upgrades](https://docs.gitlab.com/ee/update/README.html#upgrading-without-downtime).

    For this release, the upgrade process includes migrations and post-deploy migrations.
    When we upgraded our own GitLab.com instance, migrations took approximately 14 minutes and post-deploy migrations
    amounted to a total of around 12 minutes.

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

    Raspberry Pi packages will be available starting with 11.0.2.

# DEPRECATIONS
deprecations:
  - feature_name: GitLab API v3
    due: June 22, 2018
    reporter: jeremy_
    description: |
      API v4 has been the preferred version of the GitLab API since 9.0. With GitLab 11.0, API v3 is removed and no longer supported.
      See the [differences between API v3 and v4](https://docs.gitlab.com/ee/api/v3_to_v4.html).

  - feature_name: PostgreSQL < 9.5 support
    due: June 22, 2018
    reporter: jobv
    description: |
        With GitLab 10.0, [we removed PostgreSQL 9.2 support](https://about.gitlab.com/blog/2017/09/22/gitlab-10-0-released/#postgresql-9.2-support), as it became end of life.
        Going forward, GitLab requires PostgreSQL 9.5 or higher (MariaDB and MySQL support is available, but not recommended).

        If you are using the [Omnibus GitLab package](https://docs.gitlab.com/omnibus/README.html), no action is required,
        as it has automatically updated the bundled PostgreSQL to 9.6.

        [Review our database documentation for more information](https://docs.gitlab.com/omnibus/settings/database.html).

  - feature_name: Support for DSA SSH keys
    due: June 22, 2018
    reporter: jeremy_
    description: |
      Due to published weakness in the ssh-dsa algorithm, we'll [wind down support for DSA SSH keys](https://gitlab.com/gitlab-org/gitlab-ce/issues/44364).
      In 11.0, the default value for the DSA SSH keys setting is "Are forbidden". This setting is located in the [visibility and access controls](https://docs.gitlab.com/ee/user/admin_area/settings/visibility_and_access_controls.html) section of the Settings admin panel.

      This setting may be overridden if desired. Beginning in 12.0, GitLab will always reject DSA SSH keys.

  - feature_name: Mattermost configuration changes
    due: June 22, 2018
    reporter: joshlambert
    description: |
      With the release of GitLab 11.0, the number of supported Mattermost configuration
      options in `gitlab.rb` has been reduced. We 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.
      However other configuration settings now need to be set directly within
      the Mattermost Console, or via environment variables.

      Previously with both Omnibus GitLab and Mattermost Console writing to the same configuration
      file, changes could be lost.

      Learn more about [configuring Mattermost in GitLab 11.0](https://docs.gitlab.com/omnibus/gitlab-mattermost/#upgrading-gitlab-mattermost-from-versions-prior-to-11-0).

  - feature_name: Debian 7 Wheezy support
    due: June 22, 2018
    reporter: joshlambert
    description: |
      GitLab 11.0 is the last release with support for Debian 7 Wheezy.

      Debian Wheezy will be officially end of life [at the end of May 2018](https://www.debian.org/releases/wheezy/).

  - feature_name: Legacy Git storage configuration no longer supported
    due: June 22, 2018
    reporter: joshlambert
    description: |
      With the release of GitLab 9.0, we changed how to
      [configure an alternate Git storage directory](https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1363)
      in order to support multiple directories. Backwards compatibility was maintained for the
      older formats to ease the upgrade process. With GitLab 11.0, we will no longer support the
      older configuration parameter, and users need to modify their `gitlab.rb` to support the
      current [`git_data_dirs` format](https://docs.gitlab.com/omnibus/settings/configuration.html#storing-git-data-in-an-alternative-directory).

      For example if your `gitlab.rb` contains `git_data_dirs({ "default" => "/var/opt/gitlab/git-data" })`
      it should be changed to `git_data_dirs({ "default" => { "path" => "/var/opt/gitlab/git-data" } })`.

  - feature_name: Gemnasium project service
    due: June 22, 2018
    reporter: bikebilly
    description: |
      Gemnasium project service integration has been removed in GitLab 11.0 since Gemnasium ceased activities and the service is no longer available.

      For more information, see our [documentation about Gemnasium and importing to GitLab](https://docs.gitlab.com/ee/user/project/import/gemnasium.html).

  - feature_name: GitLab Runner internal Prometheus exporter metrics names change
    due: Jun 22, 2018
    reporter: bikebilly
    description: |
      With GitLab Runner 11.0, we've changed the names of exported Prometheus metrics to make them more consistent with Prometheus community naming rules.
      Old metric names will be unavailable starting with this release.

  - feature_name: Dynamically generated milestone pages
    due: August 22, 2018
    reporter: victorwu
    description: |
      GitLab currently offers both project milestones and group milestones. In particular, you can assign issues within projects
      of that group (and even within subgroups).

      There is an existing feature in GitLab that allows you to pull in multiple project milestones _with the same name_, together
      in one page. In the past, this was created to solve some of the use cases of how group milestones work now. But since we now have
      group milestones as a first-class, native object, we no longer need this dynamically generated page. We will thus
      [deprecate these dynamically generated milestone pages](https://gitlab.com/gitlab-org/gitlab-ce/issues/39545).

  - feature_name: Mattermost API v3 removed in Mattermost 5.0
    due: June 16, 2018
    reporter: victorwu
    description: |
      On June 16, 2018, Mattermost 5.0 was released. In this version, [Mattermost API v3 was removed](https://api.mattermost.com/#tag/APIv3-Deprecation), and only Mattermost API v4 is supported.
      GitLab 10.8 or lower integrates with Mattermost API v3. So if you are using GitLab 10.8 or lower currently, and upgrade your external Mattermost
      installation to 5.0, it will not work.

      GitLab 11.0 integrates with Mattermost using Mattermost API v4. Mattermost API v4 is supported in Mattermost from 4.0 and up. So if you upgrade to
      GitLab 11.0, your external Mattermost installation will still work, provided it is version 4.0 or up.

      Finally, none of this impacts you if you are using Mattermost bundled together in Omnibus. [In GitLab 11.0, Mattermost 4.10 is bundled inside Omnibus.](#omnibus-improvements)

  - feature_name: '<code>sast:container</code> job and <code>gl-sast-container-report.json</code> artifact'
    reporter: bikebilly
    due: GitLab 12.0
    description: |
      Container Scanning was previously using `sast:container` for job name and `gl-sast-container-report.json` for the artifact name.
      While these old names are still maintained they have been deprecated with GitLab 11.0 and may be removed in the next major release.
      You are advised to update your current `.gitlab-ci.yml` configuration with the [current convention](https://docs.gitlab.com/ee/user/application_security/container_scanning/).

  - feature_name: '<code>codeclimate</code> job and <code>codeclimate.json</code> artifact'
    reporter: bikebilly
    due: GitLab 12.0
    description: |
      Code Quality was previously using `codeclimate` for job name and `codeclimate.json` for the artifact name.
      While these old names are still maintained they have been deprecated with GitLab 11.0 and may be removed in the next major release.
      You are advised to update your current `.gitlab-ci.yml` configuration with the [current convention](https://docs.gitlab.com/ee/ci/examples/code_climate.html).

  - feature_name: 'GitLab Runner <code>metrics_server</code> configuration option'
    due: GitLab 12.0
    reporter: bikebilly
    description: |
      GitLab Runner can be configured to host a Prometheus exporter, that provides metrics about its internals.
      With GitLab Runner 11.0, the configuration setting that enables the exporter and defines listening address
      was renamed from `metrics_server` to `listen_address`.
      The old configuration option is deprecated and may be removed in the next major release.
