features:
# TOP FEATURE
  top:
    - name: Auto DevOps
      available_in: [core, starter, premium]
      documentation_link: 'https://docs.gitlab.com/ee/topics/autodevops/'
      reporter: bikebilly #video to be replaced
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/37115'
      description: |
        Auto DevOps brings DevOps best practices to your project by automatically
        configuring your build, test, code quality assurance, review apps, deployment,
        and monitoring in a single environment. In GitLab 10.0, we
        have introduced out-of-the-box templates to quickly set up an end-to-end DevOps
        lifecycle, built on top of [GitLab CI/CD](/product/continuous-integration/).

        As it stands, GitLab offers a single environment where a code change can not only initiate a build,
        but deploy a [Review App](/product/review-apps/) to preview your changes from
        within each merge request. During the review process GitLab's recently introduced ability to measure
        [Code Quality](https://docs.gitlab.com/ee/user/project/merge_requests/code_quality_diff.html#code-quality)
        ensures changes improve the overall quality of your software.

        After code review, GitLab's deployment capabilities easily allow you to deploy to
        canary or production environments, as well as using [GitLab Auto Deploy](https://docs.gitlab.com/ee/ci/autodeploy/quick_start_guide.html#auto-deploy-quick-start-guide)
        to deploy straight to Google Cloud. Post-deployment metrics with
        [GitLab Auto Monitoring](https://docs.gitlab.com/ee/ci/autodeploy/index.html#auto-monitoring)
        provide response and system metrics to make sure newly deployed code is performant.

        Now, GitLab 10.0 brings this entire lifecycle together in an automated way, allowing
        you to go from idea to production in the blink of an eye with GitLab Auto Devops.

        <figure class="video_container">
          <iframe src="https://www.youtube.com/embed/AgKc_KUQEtE" frameborder="0" allowfullscreen="true"> </iframe>
        </figure>

        [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/#overview)
        automatically detects, builds, tests, deploys, and monitors applications.
        Leveraging [Herokuish](https://github.com/gliderlabs/herokuish), it supports
        all languages and frameworks available through Heroku buildpacks, such as Ruby, Rails,
        Node, PHP, Python, and Java, as well as the ability to customize your own buildpacks.
        Read the [quick start guide](https://docs.gitlab.com/ee/topics/autodevops/quick_start_guide.html)
        to begin right now.

        _Auto DevOps is currently in Beta and is not recommended for production use just yet._
        {:.alert .alert-info .text-center}

        **Note:** GitLab is not affiliated with Heroku or Glider Labs.
        {:.note}

# PRIMARY FEATURES
  primary:
    - name: Group Issue Boards
      available_in: [premium]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/issue_board.html#group-level-issue-boards'
      image_url: '/images/10_0/group_issue_board.png'
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/928'
      description: |
        Many teams work as a GitLab group, with work spanning many projects in that group.
        For example, many organizations are moving toward or have already adopted a microservices
        architecture where each microservice is one code repository (housed in one GitLab project).
        This means a team may naturally be working across multiple projects, making it extremely helpful
        to manage issues across all those projects together.

        With this release we are proud to ship our
        [most requested feature](https://gitlab.com/gitlab-org/gitlab-ee/issues/928),
        GitLab's **Group-level Issue Boards**!

        Now you can manage all issues across all projects within a group single and concentrated
        view. Lists, labels, and milestones are all managed at the group level, allowing you to
        focus on the group.

    - name: New User Experience
      available_in: [core, starter, premium]
      documentation_link: '/blog/2017/09/13/unveiling-gitlabs-new-navigation/'
      documentation_text: "Read more about our new navigation"
      image_url: '/images/10_0/navigation_wireframe.png'
      image_noshadow: true
      reporter: mydigitalself
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/32794'
      description: |
        In GitLab 10.0 we are excited to unveil our new user experience, making it
        much easier to navigate GitLab!

        For the last few months, we have been [testing out](/blog/2017/07/17/redesigning-gitlabs-navigation/)
        a new way to navigate through GitLab. Based on feedback and user testing, we found
        that people had a few problems with the existing navigation. Understanding
        exactly which group or project you were currently viewing was often not
        obvious, switching between different areas of GitLab was cumbersome and
        there were a lot of inconsistencies with spacing and hierarchy that caused
        confusion.

        GitLab 10.0 introduces a more consistent navigation experience. The colored
        top bar represents all global and personal aspects of GitLab – your groups,
        projects, issues, merge requests, todos and personal information. The new left
        navigation is contextual to the group or project you are viewing and also allows
        quicker navigation between areas of the project, with pull-out menus saving you
        clicks and page loads.

        As an additional bonus, we've also brought back the ability to personalize your
        experience, allowing you to change the color theme of GitLab because, well, not
        everyone loves purple like we do!

    - name: Protected GitLab Runners
      available_in: [core, starter, premium]
      documentation_link: 'https://docs.gitlab.com/ee/ci/runners/README.html#protected-runners'
      image_url: '/images/10_0/protected_runners.png'
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/33281'
      description: |
        When running sensitive jobs in CI/CD pipelines, for example deployments
        to production environments, you want to be sure that nobody can access credential
        information or private configuration options.
        In order to avoid any data leakage, you can set the protected flag for a
        specific GitLab Runner, so only jobs running on
        [protected branches](https://docs.gitlab.com/ee/user/project/protected_branches.html)
        are picked up.

        Combining this feature with [mandatory approval](https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_approvals.html)
        and [Runner selection by tags](https://docs.gitlab.com/ee/ci/runners/README.html#using-tags),
        you can guarantee that **only trusted code** is executed on the Protected Runner.

    - name: Object Storage for Git LFS
      available_in: [premium]
      documentation_link: 'https://docs.gitlab.com/ee/administration/lfs/lfs_administration.html#setting-up-s3-compatible-object-storage'
      image_url: '/images/10_0/git_lfs.png'
      reporter: mydigitalself
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/2841'
      description: |
        [Git LFS](https://docs.gitlab.com/ee/workflow/lfs/manage_large_binaries_with_git_lfs.html#git-lfs)
        provides a great way to efficiently store large files in Git.

        Large files have a habit of using a lot of disk space and managing very large
        storage clusters can become painful as usage grows.

        GitLab Enterprise Edition Premium now offers the ability to store LFS files in
        an object storage system such as the open source [Minio](https://minio.io) or [Amazon's S3](https://gitlab.com/gitlab-org/gitlab-ee/issues/2841).

    - name: SSH Key Length Restrictions
      available_in: [core, starter, premium]
      gitlab_com: false
      image_url: '/images/10_0/ssh_keys_restrictions_settings.png'
      documentation_link: 'https://docs.gitlab.com/ee/security/ssh_keys_restrictions.html'
      documentation_text: "Read through the documentation on SSH Restrictions"
      reporter: mydigitalself
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/2841'
      description: |
        With thanks to our community contributor [Corey Hinshaw](https://gitlab.com/electrickite)
        GitLab 10.0 now allows administrators to add restrictions on SSH keys.

        This functionality allows administrators to restrict not only the type of
        SSH keys that may be used, but also the minimal key length, giving you a more
        secure way to manage your GitLab SSH access environment.

# SECONDARY FEATURES
  secondary:
    - name: API Support for Wikis
      available_in: [core, starter, premium]
      documentation_link: 'https://docs.gitlab.com/ee/api/wikis.html'
      documentation_text: "Read through the documentation on Wikis API"
      reporter: mydigitalself
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/12747'
      description: |
        You can now use the GitLab API to work with wiki pages! With the additions
        to the API, it is possible to get a list of all wiki pages, get a particular page,
        create a new wiki page, as well as edit and delete pages, providing a great way
        to programmatically access GitLab's wiki functionality.

        Many thanks to our community contributor, [Vitaliy Klachkov](https://gitlab.com/blackst0ne) for adding this functionality.

    - name: Weekly View for Cycle Analytics
      available_in: [core, starter, premium]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/cycle_analytics.html'
      documentation_text: "Read through the documentation on Cycle Analytics"
      reporter: mydigitalself
      image_url: '/images/10_0/7_day_cycle_analytics.png'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/12747'
      description: |
        Cycle Analytics measures the time it takes to go from an idea to production
        for each project you have. This is achieved not only by indicating the
        total time it takes to reach that point, but the total time is broken down
        into the multiple stages an idea has to pass through to be shipped.

        With thanks to our community contributor, [Mehdi Lahmam](https://gitlab.com/mehlah)
        it is now possible to view your cycle over a seven-day period which is great
        for teams with very short release cycles.

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

        #### Most interesting changes:

        - Register command [locks Runner to a project by default](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/657)
        - Add [handling of non-existing images for Docker >= 17.07](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/664)
        - [Fix variable file permission issue](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/655) with Kubernetes executor

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

    - name: New GitLab Runner Repository
      available_in: [core, starter, premium]
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-runner/issues/1195'
      description: |
        At 12th September 2017 we've moved GitLab Runner to a new repository path.
        From now on Runner is available at [https://gitlab.com/gitlab-org/gitlab-runner](https://gitlab.com/gitlab-org/gitlab-runner)!

        Please update your bookmarks!

    - name: GitLab Runner Locked to Project by Default
      available_in: [core, starter, premium]
      documentation_link: 'https://docs.gitlab.com/runner/register/'
      documentation_text: "Read through the documentation on the Runner registration process"
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-runner/issues/2615'
      description: |
        During the [initial registration](https://docs.gitlab.com/runner/register/) of a new GitLab Runner,
        you are asked if you want to **lock it to the project** for which you are providing the token.
        Before GitLab 10.0, the default choice was `false`, but it was not clear that this allows any Master
        of the project to enable the Runner also for other projects, and this might be a security risk.
        With GitLab 10.0, the default choice is now `true`, so the Runner cannot be easily assigned to other projects.

        This behavior can be changed later in the Runner settings, if there is the need. It can be also set
        during registration manually (for interactive mode) or with the `--locked=false` option (for
        non-interactive mode).

    - name: New Predefined Variables for User Identity
      available_in: [core, starter, premium]
      documentation_link: 'https://docs.gitlab.com/ee/ci/variables/#predefined-variables-environment-variables'
      documentation_text: "Read through the documentation on Predefined Variables for CI"
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/26692'
      description: |
        When running pipelines, we have a lot of **environment variables** that are automatically set by GitLab,
        giving your scripts the ability to access important information. Starting with GitLab 10.0, two new
        variables, `GITLAB_USER_NAME` and `GITLAB_USER_LOGIN`, are now available to access the **full name** and
        the **login username** associated to the account that is running the job.

    - name: Simplified Project Permissions
      available_in: [core, starter, premium]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/settings/#sharing-and-permissions'
      image_url: '/images/10_0/simplified_project_permissions.png'
      reporter: mydigitalself
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/32665'
      description: |
        One of GitLab's many distinguishing features is the granularity of permissions
        and access to project capabilities.

        In GitLab 10.0 we have simplified the user interface, allowing you to maintain
        precise control of your project visibility, features and permissions, but doing so
        in an easy-to-use and beautiful interface.


    - name: Variables for Pipeline Schedules API
      available_in: [core, starter, premium]
      documentation_link: 'https://docs.gitlab.com/ee/api/pipeline_schedules.html#pipeline-schedule-variable'
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/34518'
      description: |
        In GitLab 9.2 we introduced [Pipeline Schedules](/blog/2017/05/22/gitlab-9-2-released/#pipeline-schedules),
        and in the following release we added
        [API](/blog/2017/06/22/gitlab-9-3-released/#api-support-for-pipeline-schedules) and
        [variables](/blog/2017/07/22/gitlab-9-4-released/#variables-in-pipeline-schedules) support.
        In GitLab 10.0, we complete the cycle adding **variables support** also to **API** calls.
        Now automatic interaction with Pipeline Schedules by third-party applications can benefit of more flexibility.

    - name: Improved Subgroup Permissions
      available_in: [core, starter, premium]
      documentation_link: 'https://docs.gitlab.com/ee/user/group/subgroups/' # Mike to check: doc pending update
      documentation_text: "Read through the documentation on Subgroups"
      reporter: mydigitalself
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/30473'
      description: |
        In [GitLab 9.0](/blog/2017/03/22/gitlab-9-0-released/#subgroups-ce-ees-eep)
        we released subgroups, giving you more flexibility in how you organize
        projects and groups inside of GitLab. If you haven't tried them out before,
        you can find out more about subgroups in our [documentation](https://docs.gitlab.com/ee/user/group/subgroups/).

        We've now added the ability to allow owners to create subgroups if group creation
        has been restricted, making it easier for delegated users to manage the group
        structure of GitLab.

    - name: Share Locking Support for Subgroups
      available_in: [core, starter, premium]
      documentation_link: 'https://docs.gitlab.com/ee/user/group/index.html#share-with-group-lock'
      documentation_text: "Read through the documentation on share locking"
      reporter: mydigitalself
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/30550'
      description: |
        GitLab provides the ability to share projects between different groups, giving
        you even more flexibility with project structure and permissions.

        [Share locking](https://gitlab.com/help/workflow/groups.md#prevent-projects-in-this-group-from-sharing-a-project-with-another-group)
        provides the ability to restrict projects in particular groups from being shared, to enforce
        centralized security and policy.

        Share locking has now been extended to subgroups, allowing subgroups to either
        inherit or override share locking from the parent group, giving more granular
        control over how projects can be distributed.

    - name: Access GitLab Commits and Branches in JIRA Development Panel
      available_in: [premium]
      documentation_link: 'https://docs.gitlab.com/ee/integration/jira_development_panel.html'
      documentation_text: "Read through the documentation on JIRA Development Panel integration"
      image_url: '/images/10_0/jira_dev_panel.png'
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/2381'
      description: |
        Many GitLab users are also JIRA users. With this release, we are significantly
        improving our JIRA integration by introducing linked commits and branches in a JIRA
        issue's [development panel](https://confluence.atlassian.com/jirasoftwarecloud/viewing-the-development-information-for-an-issue-777002795.html).
        As you are interacting with a JIRA issue, you can now quickly click through to associated
        GitLab commits or branches, further tightening the GitLab-JIRA integration.

    - name: Dedicated Page for Service Desk Issues
      available_in: [premium]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/service_desk.html'
      documentation_text: "Read through the documentation on Service Desk"
      image_url: '/images/10_0/service_desk_page.png'
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/3049'
      description: |
        Previously, managing Service Desk issues required searching for issues authored by
        the Support Bot on a project's issue page. We now have a dedicated page accessible in the
        navigation that does that for you automatically. We also display the support email
        address itself on the page, allowing you to share it easily with anyone who you want
        to send in support requests with Service Desk.

    - name: Time Tracking for Issues CSV Export
      available_in: [starter, premium]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/issues/csv_export.html'
      documentation_text: "Read through the documentation on CSV Export"
      image_url: '/images/10_0/csv_export.png'
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/1406'
      description: |
        We have now included time tracking information (time estimate and time spent) in the
        existing issues CSV export functionality. This allows roles such as team leads or
        managers to manage time tracking information easily in issues using spreadsheets.

        Thank you [Bohdan V.](https://gitlab.com/g3dinua) for the contribution.

    - name: Group Merge Requests Search and Filter Bar
      available_in: [core, starter, premium]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/merge_requests/#merge-requests-per-group'
      documentation_text: "Read through the documentation on Group Merge Requests"
      image_url: '/images/10_0/merge_requests_search_bar.png'
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/36703'
      description: |
        We have updated the group merge requests list page with the latest
        search and filter bar UI. This allows you to narrow down the
        merge requests you care about quickly, by author, assignee, milestone, label,
        or weight, similarly to what you've been able to do for a few releases now
        on the issue side.

        Thank you [Hiroyuki Sato](https://gitlab.com/hiroponz) for the contribution.

    - name: Filter by Reactions
      available_in: [core, starter, premium]
      documentation_link: 'https://docs.gitlab.com/ee/user/search/#issues-and-merge-requests-per-project'
      documentation_text: "Read through the documentation on searching and filtering through GitLab"
      image_url: '/images/10_0/filter_my_reaction.png'
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/35618'
      description: |
        Throughout GitLab, when you are filtering issues and merge requests, you
        can now filter by reactions you have added. You can use this as a generalized
        bookmarking feature. Just react to issues and merge requests by awarding
        different emoji, and now you access those objects quickly by filtering on them.

        Thank you [Hiroyuki Sato](https://gitlab.com/hiroponz) for the contribution.

    - name: Move Issues from the Sidebar
      available_in: [core, starter, premium]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/issues/moving_issues.html'
      documentation_text: "Read through the documentation on Moving Issues"
      image_url: '/images/10_0/move_issue.png'
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/34261'
      description: |
        The move issue functionality is now in the issue sidebar. This groups other
        useful actions outside the main issue area, which is now focused on the title
        and description only.

    - name: Move Issue Quick Action
      available_in: [core, starter, premium]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/quick_actions.html'
      documentation_text: "Read through the documentation on Quick Actions"
      image_url: '/images/10_0/move_quick_action.png'
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/26925'
      description: |
        There is now a move issue quick action to speed up your workflows even more.
        So you can now type comments, and perform yet another action (moving an issue),
        all within the comment box itself.

        Thank you [Manolis](https://gitlab.com/frite) for the contribution.

    - name: Merge Request Inherits Issue Milestone and Labels
      available_in: [core, starter, premium]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/issues/issues_functionalities.html#18-new-merge-request'
      documentation_text: "Read through the documentation on creating new MRs from Issues"
      image_url: '/images/10_0/inherit_milestone_labels.png'
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/35343'
      description: |
        If you are using milestones and labels for your merge requests, you may
        often be copying these objects from the issue to an associated merge request.
        Now when you create a merge request from within an issue using the dedicated
        button, the milestone and labels are automatically inherited into the merge
        request.

        Thank you [haseeb](https://gitlab.com/haseebeqx) for the contribution.

    - name: Redesigned System Notes Icons
      available_in: [core, starter, premium]
      documentation_link: 'https://docs.gitlab.com/ee/development/ux_guide/basics.html#icons'
      documentation_text: "Check out our new beautiful icons set!"
      image_url: '/images/10_0/system_note_icons.png'
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/35343'
      description: |
        As part of our continuing effort to [define and distinguish our unique
        GitLab personality](https://gitlab.com/gitlab-org/gitlab-ce/issues/32894),
        we now have a redesigned set of system note icons.

    - name: Automatically Resolve Outdated MR Discussions
      available_in: [core, starter, premium]
      documentation_link: 'https://docs.gitlab.com/ee/user/discussions/index.html#automatically-resolve-merge-request-diff-discussions-when-they-become-outdated'
      documentation_text: "Read through the documentation on GitLab Discussions"
      image_url: '/images/10_0/automatically_resolve_outdated_discussions.png'
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/36994'
      description: |
        For some users, resolving a merge request diff discussion means simply pushing new code to replace
        the code in question. We've introduced a merge request setting to achieve exactly that. If the
        setting is on, any diff discussions will be resolved if a push makes that diff section outdated.
        Note that discussions on lines that don't change and top-level resolvable discussions are _not_
        automatically resolved.

        Thank you [Ashley Dumaine](https://gitlab.com/AshleyDumaine) for the contribution.

    - name: Improved Monitoring Dashboard
      available_in: [core, starter, premium]
      documentation_link: 'https://docs.gitlab.com/ee/ci/environments.html#monitoring-environments'
      documentation_text: "Read through the documentation on monitoring environments with Prometheus"
      image_url: '/images/10_0/prometheus_dashboard.png'
      reporter: joshlambert
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/33345'
      description: |
        The environment monitoring dashboard has been significantly improved, with an improved look and feel as well as support for multiple series in a single chart.
        This provides a deeper-level insight into performance as well as easy comparisons. For example, an application's throughput can now be broken out by HTTP response type,
        providing a single chart for both successful and failed request rates, as well as potential missing pages.

    - name: LDAP Group Sync Improvements for External Users
      available_in: [starter, premium]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/ee/administration/auth/ldap-ee.html#group-sync'
      documentation_text: "Read through the documentation on LDAP Group Sync"
      reporter: mydigitalself
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/2468'
      description: |
        LDAP Group Sync is available in GitLab Enterprise Edition and provides a
        great hassle-free way to manage user permissions by leveraging your existing
        LDAP group system and permissions.

        GitLab further supports [external users](https://docs.gitlab.com/ee/user/permissions.html#external-users-permissions)
        allowing more restrictive control on projects on a case-by-case basis.

        In GitLab 10.0 synchronizing external user permissions will happen at login, in addition
        to the existing periodic synchronization. This means that any changes to permissions
        in your LDAP system can be immediately available to the user after logging in and denying
        access to unauthorized projects.

    - name: LDAP Group Sync API
      available_in: [starter, premium]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/ee/api/groups.html#sync-group-with-ldap'
      documentation_text: "GitLab Enterprise Edition Group API"
      reporter: mydigitalself
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/2304'
      description: |
        GitLab's LDAP Group Sync is now available via API, allowing you to programmatically
        request a sync event. This means that any group automation such as creation of groups
        performed via the API can immediately be programmatically synchronized to LDAP with one
        simple API call.

    - name: New Filter for Archived Projects
      available_in: [core, starter, premium]
      documentation_link: 'https://docs.gitlab.com/ee/user/search/#projects'
      documentation_text: "Read through the documentation on searching and filtering through GitLab"
      image_url: '/images/10_0/show_archived_projects_only.png'
      reporter: mydigitalself
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/2304'
      description: |
        With thanks (again!) to our community contributor [Mehdi Lahmam](https://gitlab.com/mehlah)
        it is now possible to filter the project view to show archived projects only.

        This may be useful when managing projects to see a distinct list of all archived projects
        and allow for easy deletion of archived projects by administrators.

    - name: 'LDAP Config "verify_certificates" Defaults to Secure'
      available_in: [core, starter, premium]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/ee/administration/auth/ldap.html'
      documentation_text: "Read through the admin documentation on LDAP"
      reporter: mkozono
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/33662'
      description: |
        The LDAP config option `verify_certificates` now defaults to true for security.
        This option was added in 9.4.2 but defaulted to false for backwards-compatibility.

        Installations that are using `start_tls` or `simple_tls` for the encryption
        parameter and that unknowingly do not have SSL configured properly between the
        LDAP server and the GitLab server, may break if the LDAP server's SSL
        certificate cannot be verified by the GitLab server.

    - name: Internationalized Project Activity Page
      available_in: [core, starter, premium]
      documentation_link: 'http://translate.gitlab.com'
      documentation_text: "Get involved translating GitLab"
      reporter: mydigitalself
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/32795'
      description: |
        As part of our [ongoing effort](https://gitlab.com/gitlab-org/gitlab-ce/issues/4012) to
        translate GitLab into new languages, the  Project Activity Page has now been made ready for translating.

        We have recently created a [Translation Community on CrowdIn](http://translate.gitlab.com) making
        it easy for anyone to help translate pages on GitLab. If you wanted to get involved, please
        feel free to sign up through the community.

    - name: Streamlined Omnibus GitLab Installation
      available_in: [core, starter, premium]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/omnibus/'
      documentation_text: "Read through the documentation on Omnibus GitLab"
      reporter: joshlambert
      issue_url: 'https://gitlab.com/gitlab-org/omnibus-gitlab/issues/2619'
      description: |
        Installation of GitLab is now easier and faster than ever! GitLab 10 adds support for specifying the GitLab URL
        directly when installing the package. When specified, GitLab will automatically be reconfigured with the
        URL and started, removing two steps from the installation process.

    - name: GitLab Geo Improvements
      available_in: [premium]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/ee/gitlab-geo/'
      documentation_text: "Read through the documentation on GitLab Geo"
      image_url: '/images/10_0/geo_improvements.png'
      reporter: stanhu
      description: |
        Notable changes shipped with GitLab 10.0:

        - GitLab Geo has fully removed the use of system hooks. If you upgrade to GitLab 10.0, you MUST
          [enable SSH key lookups via the database](https://docs.gitlab.com/ee/gitlab-geo/configuration.html#upgrading-geo).
          We highly recommend Geo installations either [upgrade to CentOS 7.4](https://lists.centos.org/pipermail/centos-announce/2017-September/022532.html) or use Ubuntu 16.04 to get the required OpenSSH version.
        - We [improved the Geo download scheduler](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2796) to skip over projects that recently failed.
        - We added improvements to the admin page for monitoring the database replication lag and log cursor state under an "Advanced" toggle (see screenshot below).
        - See the full list of changes [here](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&label_name[]=Geo&milestone_title=10.0).

    - name: Omnibus Improvements
      available_in: [core, starter, premium]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/omnibus/'
      documentation_text: "Read through the documentation on Omnibus GitLab"
      reporter: joshlambert
      description: |
        * Ruby has been updated to [2.3.5](https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1930).
        * libyaml has been [updated to 0.1.7](https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1930).

    - name: Performance Improvements
      available_in: [core, starter, premium]
      performance_url: 'https://gitlab.com/groups/gitlab-org/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=10.0&label_name[]=performance'
      documentation_text: "Take a look at the performance improvements in GitLab 10.0"
      reporter: mydigitalself
      issue_url: 'https://gitlab.com/groups/gitlab-org/issues?state=all&utf8=%E2%9C%93&milestone_title=10.0&label_name%5B%5D=Deliverable&label_name%5B%5D=performance'
      description: |
        With every release we aim to make GitLab faster, more available, and more stable.
        [We're committed](/handbook/product/#performance) not only to making
        individual instances of GitLab even faster, but also to greatly improving
        the performance of GitLab.com, an instance that hosts 1 million users!

        In GitLab 10.0 we have doubled down on this commitment and addressed more
        performance issues than any other previous release.

        We are addressing high memory usage issues, making numerous pages a lot
        faster as well as improving the speed of creating projects and performing commits.

    - name: GitLab Mattermost 4.2
      available_in: [core, starter, premium]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/omnibus/gitlab-mattermost/'
      documentation_text: "Read through the documentation on GitLab Mattermost"
      reporter: joshlambert
      description: |
        GitLab 10.0 includes [Mattermost 4.2](https://about.mattermost.com/blog/mattermost-4-2/), an
        [open source Slack-alternative](https://about.mattermost.com/) whose newest release includes interactive
        message buttons to simplify complex workflows, plus much more.

        This version includes [security updates](http://about.mattermost.com/security-updates/) and an upgrade is recommended.

# MVP
mvp:
  fullname: Hiroyuki Sato
  gitlab: hiroponz
  description: |
    Once again, we've had an incredible number of [contributions](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?scope=all&utf8=%E2%9C%93&state=all&milestone_title=10.0&label_name[]=Community%20Contribution)
    from the community, illustrating the power of open source software and its benefit to GitLab and
    all of our users and customers.

    Hiroyuki has provided [numerous contributions](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?scope=all&utf8=%E2%9C%93&state=all&author_username=hiroponz&milestone_title=10.0)
    in GitLab 10.0, including performance improvements, enhancing searching and filtering issues and merge requests,
    as well as one of our favorite features of being able to [filter issues](#filter-by-reactions) by your own reactions so
    you can see what you've liked (or not!).

    Thank you to everyone for your contributions, and a special thank you to Hiroyuki for such
    amazing work.

# COVER IMAGE LICENCE
cover_img:
  image_url: 'https://commons.wikimedia.org/wiki/File:Compass_Study_(4925267732).jpg'
  licence: CC 2.0
  licence_url: 'https://creativecommons.org/licenses/by/2.0/'

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

# UPGRADE BAROMETER
barometer:
  description: |

    To upgrade to GitLab 10.0 from the latest 9.5 version, no downtime is required.
    To upgrade without downtime, please consult the
    [documentation on downtimeless upgrades](https://docs.gitlab.com/ee/update/README.html#upgrading-without-downtime).

    If you are upgrading from a version prior to 9.5, migrations will take a
    significant amount of time based on the size of your database. For example on GitLab.com,
    the set of migrations would take over 24 hours. For larger deployments, we recommend
    upgrading to 9.5 first and allowing background migrations to run. Once completed,
    then continue and upgrade to GitLab 10.0.

    You can check the status of background migrations by running this command from the Rails console:
    ```Sidekiq::Queue.new('background_migration').size```

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

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

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

# DEPRECATIONS
deprecations:
  - feature_name: PostgreSQL 9.2 Support
    due: September 22nd, 2017.
    reporter: joshlambert
    description: |
      With the release of GitLab 10.0 on September 22nd, support for Postgres 9.2
      will end and it will be removed from the [Omnibus GitLab package](https://docs.gitlab.com/omnibus/README.html).
      For deployments using packaged Postgres, upgrading to GitLab 10.0 requires
      the database to already be running version 9.6.

      If you are upgrading from at least GitLab 9.0, your database is already running
      version 9.6. If you are running a version older than 9.0, please
      [upgrade your database](https://docs.gitlab.com/omnibus/settings/database.html#upgrade-packaged-postgresql-server)
      to prepare for GitLab 10.

      PostgreSQL 9.2 is [end of life](https://www.postgresql.org/support/versioning/) in September,
      five years after it was first released.
  - feature_name: API V3
    due: GitLab 11.0
    reporter: mydigitalself
    description: |
      In GitLab 8.17 we [announced](https://about.gitlab.com/blog/2017/02/22/gitlab-8-17-released/) the deprecation of API v3.

      We are still seeing a high volume of traffic on GitLab.com using API v3
      requests.

      API v3 will be removed in GitLab 11 and we just wanted to ensure that developers
      were migrating to API v4. Please refer to our [documentation](https://docs.gitlab.com/ee/api/v3_to_v4.html) that shows changes
      between the two API versions.
  - feature_name: Koding Integration
    due: GitLab 11.0
    reporter: mydigitalself
    description: |
      The GitLab Koding integration is being removed as we continue to enhance
      GitLab's in-line editing capabilities.

      From GitLab 10.0 it will no longer be possible to activate Koding integration.
      Existing installations that are currently using Koding may continue to do so
      until GitLab 11.0 when this functionality will be completely removed.
  - feature_name: TLSv1 no Longer Accepted by Default
    due: September 22nd, 2017.
    reporter: joshlambert
    description: |
      GitLab 10 will no longer accept TLSv1 by default. If you would like to
      continue to accept TLSv1 connections, it can be added back to the list of
      supported protocols by editing the `nginx['ssl_protocols']` field in `gitlab.rb`.
  - feature_name: GitLab Git HTTP Server Configuration Support Removed
    due: September 22nd, 2017.
    reporter: joshlambert
    description: |
      Since GitLab 8.2, we have used [gitlab-workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse)
      to process Git HTTP traffic. Earlier versions of GitLab used
      [gitlab-git-http-server](https://gitlab.com/gitlab-org/gitlab-git-http-server), and configuration
      entries for it have been ignored. With GitLab 10, we will be removing the code to recognize the
      long-deprecated configuration parameters for gitlab-git-http-server. In the event your `gitlab.rb`
      configuration file contains these entries, they should be removed or GitLab configuration will fail.
  - feature_name: Private Tokens
    due: September 22nd, 2017.
    description: |
      Private tokens allow a mechanism to access the API with a token unique to your
      user account.

      [Personal Access Tokens](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html)
      provide more granular access to GitLab via the API and are recommended over
      using Private Tokens.

      Private Token support will be removed in GitLab 10.2 as we feel they are less
      secure that Personal Access Tokens.
  - feature_name: 'LDAP Config "verify_certificates" Defaults to Secure'
    due: September 22nd, 2017.
    reporter: mkozono
    description: |
      The LDAP config option `verify_certificates` now defaults to true for security.
      This option was added in 9.4.2 but defaulted to false for backwards-compatibility.

      Installations that are using `start_tls` or `simple_tls` for the encryption
      parameter and that unknowingly do not have SSL configured properly between the
      LDAP server and the GitLab server, may break if the LDAP server's SSL
      certificate cannot be verified by the GitLab server.
  - feature_name: Custom SSH Client Configuration for the Git User
    due: September 22nd, 2018.
    reporter: nick.thomas
    description: |
      Currently, the Git user on a GitLab server can have custom SSH client configuration
      placed into `~git/.ssh/config` `.id_rsa` and other configuration files are also picked up automatically.

      This custom manual configuration is automatically picked up and used in a number of places.
      However, it's insecure as there are no per-gitlab-user access controls on use of the key.
  - feature_name: Drop Support of Legacy Git Storage Configuration
    due: March 22nd, 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. In a future release of GitLab, we will no longer support the
      older configuration parameter, and users should 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: Keyword 'types' in '.gitlab-ci.yml'
    due: March 22nd, 2018.
    reporter: bikebilly
    description: |
      The `types` keyword, that has been replaced by `stages` long time ago,
      is deprecated and will be removed in a future release of GitLab.
  - feature_name: Build Badges
    due: March 22nd, 2018.
    description: |
      Old badges paths for **builds** are now deprecated in favor of **pipeline**
      badges, and will be removed in a future release of GitLab.
  - feature_name: Auto Deploy
    due: November 22nd, 2017.
    reporter: bikebilly
    description: |
      Auto Deploy is now part of Auto DevOps, and no longer needs to have standalone templates.
      With the incorporation in Auto DevOps, it has been improved with Helm Charts support
      and persistent database instances, to make deployments even more usable for production.
  - feature_name: Legacy Triggers
    due: January 22nd, 2018.
    reporter: bikebilly
    description: |
      Triggers with the legacy label do not have an associated user and only have
      access to the current project. You are advised to take ownership of any legacy triggers.
  - feature_name: Code Quality 'codeclimate' Job Name
    due: March 22nd, 2018.
    reporter: bikebilly
    description: |
      In the first iteration of GitLab Code Quality, we hardcoded detection of the job by `codeclimate`.
      We now officially look for `codequality` jobs, even if the old `codeclimate` is still working.
  - feature_name: Runner's 'docker-ssh' and 'docker-ssh+machine' executors
    due: March 22nd, 2018.
    reporter: tmaczukin
    description: |
      Two GitLab Runner's executors – `docker-ssh` and `docker-ssh+machine` – are now deprecated.
      They will be removed in one of the upcoming releases.

      You can read more about the decision [in the issue](https://gitlab.com/gitlab-org/gitlab-runner/issues/2732).
  - feature_name: Runner's exec and service-related commands
    due: March 22nd, 2018.
    reporter: tmaczukin
    description: |
      We're also deprecating all service-management-related commands
      (`stop`, `start`, `restart`, `status`, `install`, `uninstall`). They will be removed in one of the upcoming releases.

      You can read more about the decision [in the issue](https://gitlab.com/gitlab-org/gitlab-runner/issues/2710).
