features:
# TOP FEATURE
  top:
    - name: Incremental rollout deployments
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/topics/autodevops/index.html#incremental-rollout-to-production'
      documentation_text: "Read through the documentation on incremental rollout deployments"
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/5415'
      image_url: '/images/10_8/incremental-rollout.png'
      description: |
        When your software application goes through major changes, you may want to deploy the latest version only to a small subset
        of your fleet to get feedback and to make sure that no problems are present. You can repeat this process in small steps,
        increasing the percentage of users that will use the new release. Eventually, if no problems are detected, the deployment will
        replace the previous version. Otherwise, you're able to revert the changes without creating major problems for users.

        With GitLab 10.8, you can now roll out your latest code incrementally to 10, 25, 50, or 100 percent of your pods. This behavior is
        already supported by [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/), but should be explicitly enabled by setting
        the `INCREMENTAL_ROLLOUT_ENABLED` environment variable.

# PRIMARY FEATURES
  primary:
    - name: Push Mirroring now open source
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/repository/repository_mirroring.html#pushing-to-a-remote-repository-core'
      documentation_text: "Read through the documentation on Push Mirroring"
      reporter: jramsay
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/42099'
      image_url: '/images/10_8/push_mirroring.png'
      description: |
        Repository mirroring allows you to replicate Git repositories from one
        location to another. This makes it easier to work with multiple GitLab
        instances, like mirroring your team's work to a customer's private GitLab
        instance. Push mirroring also makes it easier to move a project to
        GitLab from elsewhere, without disruption, by keeping the old repository
        up to date.

        Push mirroring, now available in Core, was previously available in GitLab Starter.

    - name: Interactive feedback in security reports (alpha)
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/merge_requests/#interacting-with-security-reports'
      documentation_text: "Read through the documentation on interacting with security reports"
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/5151'
      image_url: '/images/10_8/interactive_reports.png'
      description: |
        Security reports show which vulnerability may affect your software, but action is needed in order to address these and ensure
        the security of your product.

        With GitLab 10.8, you can create an issue to solve a vulnerability directly from
        the security report. If it is a false positive, you can also dismiss the entry.
        This feedback is immediately visible in the report itself.

        You can follow the future development of this feature in this [epic](https://gitlab.com/groups/gitlab-org/-/epics/202).

    - name: Fuzzy file finder in the Web IDE
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/web_ide'
      documentation_text: "Read through the documentation on Web IDE"
      image_url: '/images/10_8/web_ide_fuzzy.png'
      reporter: jramsay
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/44841'
      description: |
        In the Web IDE, files can now be quickly opened using the fuzzy file
        finder, making it easier to navigate large projects. The fuzzy
        file finder can be opened using the `Cmd + p`/`Ctrl + p` keyboard shortcut.

        Previously, files could only be opened by browsing the file tree.

    - name: Stage and commit by file in the Web IDE
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/web_ide'
      documentation_text: "Read through the documentation on Web IDE"
      image_url: '/images/10_8/web_ide_staging.png'
      reporter: jramsay
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/44842'
      description: |
        Changes can now be staged file by file in the Web IDE, allowing you
        to stage and commit your changes in smaller commits. As you make
        changes, they are collected in the unstaged changes list. From this
        list you can select which files to add to the staged changes list,
        which is the list of changes that will be part of the your next commit.

    - name: Group milestone burndown chart
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/milestones/burndown_charts.html'
      documentation_text: "Read through the documentation on burndown charts"
      image_url: '/images/10_8/group-burndown-chart.png'
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/3064'
      description: | # supports markdown
        Many teams use the [burndown chart](https://docs.gitlab.com/ee/user/project/milestones/burndown_charts.html) in their projects
        to track progress over a milestone. But as many of the teams have started to adopt groups and subgroups, folks
        have also been asking for the same functionality associated with groups.

        In this release, we are shipping burndown charts associated with group milestones. Analagous to project milestone burndown charts,
        a group milestone burndown chart is associated with a group milestone. All issues that are assigned that group milestone will "burndown" throughout
        that milestone, allowing you to see progress in a visualization. This allows you see the trend of work being completed over time, enabling you
        to more quickly anticipate any risk of not finishing scoped work and proactively managing that ahead of time.

        Group milestone burndown charts allow for both issue count and issue weight in their calculations, just like their project milestone counterparts.
        Additionally, group milestone burndown charts automatically account for subgroups. If your group has many layers of subgroups with issues assigned
        to that group milestone, they will all be accounted for in the burndown.

    - name: GitLab Prometheus service metrics now GA, on by default for new installations
      available_in: [core, starter, premium, ultimate]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/ee/administration/monitoring/prometheus/gitlab_metrics.html'
      documentation_text: "Read through the documentation on monitoring GitLab with Prometheus"
      reporter: joshlambert
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/43660'
      image_url: '/images/10_8/gitlab_dashboard.png'
      description: |
        GitLab is often at the heart of an organization's software delivery lifecycle, so it is important to ensure it is healthy
        and responsive. We have already added Prometheus metrics to dependencies like Redis and Postgres, and
        [introduced experimental GitLab metrics in 9.3](/blog/2017/06/22/gitlab-9-3-released/#additional-gitlab-service-metrics).
        Since that release, we have instrumented additional portions of our codebase and reduced the impact, and now utilize these metrics to operate GitLab.com.

        With these improvements, we are proud to announce that Prometheus monitoring of GitLab is now generally available in
        10.8, and will be on by default for all new installations going forward. We have also released a
        [sample Grafana dashboard](https://grafana.com/dashboards/5774) to easily visualize these metrics.

# SECONDARY FEATURES
  secondary:
    - name: Enforce terms of service acceptance
      available_in: [core, starter, premium, ultimate]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/ee/user/admin_area/settings/terms.html'
      documentation_text: "Read through the documentation on Enforce terms of service acceptance"
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18570'
      description: |
        As part of [preparing GitLab.com and our users for GDPR](/blog/2018/05/01/new-gitlab-com-terms-of-service/),
        we asked GitLab.com users to review and accept updated Terms of Service. Rather than making this a one-time
        functionality that we throw away afterward, we decided to build the feature directly
        into GitLab, so that self-hosted users can use it going forward as well.

        When an instance admin has activated the feature in GitLab, users will be required
        to review a message representing the Terms of Service
        and accept them before continuing to use GitLab. As long as a user has not yet
        accepted, GitLab will be blocked via the web, API, and Git traffic.

        This message is entirely customizable in the admin settings
        and is powered by [GitLab-flavored Markdown](https://docs.gitlab.com/ee/user/markdown.html#gitlab-flavored-markdown-gfm),
        so you can even link to other pages for users to review detailed information.

        The accepts are logged in the database so that you have an audit trail for
        any compliance purposes your team may need.

    - name: Epic roadmap search and filter bar
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/group/roadmap/'
      documentation_text: "Read through the documentation on roadmaps"
      image_url: '/images/10_8/search-filter-bar-epics.png'
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/3729'
      description: | # supports markdown
        The search and filter bar is a very useful and helpful UI used throughout GitLab and is familiar to users. So, we decided to leverage
        this design to allow for searching and filtering roadmap bars in the roadmap view.

        With this release, you can now filter epics by author and label in the roadmap view. Additionally, you can even search by the title and
        description of epics. This allows users to see epics relevant to them and their teams in the roadmap view, and even bookmark links to save searches.

    - name: Discussions in API
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/api/discussions.html'
      documentation_text: "Read through the documentation on Discussions in API"
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/43557'
      description: | # supports markdown
        Discussions (threaded comments) appear in the GitLab web interface in a number of places, including issues, merge requests,
        epics, snippets, and commits. With this release, we have now opened up the API so that you can access and manage these
        discussions directly via the GitLab API, allowing you even more flexibility in your custom workflows.

    - name: SAST for PHP and Java Gradle
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks'
      documentation_text: "Read through the documentation on SAST"
      image_url: '/images/10_8/sast_php.png'
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/5378, https://gitlab.com/gitlab-org/gitlab-ee/issues/5230'
      description: |
        Static Application Security Testing is effective only in the event that your
        project is using a programming language supported by one of the
        tools integrated in GitLab. That is why we are increasing their number
        with each release, adding the most commonly used languages.

        In GitLab 10.8, projects written in PHP and Java with Gradle can be automatically
        checked for security vulnerabilities. No need to specify the language,
        it will be autodetected at runtime for an easy user experience.

    - name: Specify variables for manual pipelines
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/ci/pipelines.html'
      documentation_text: "Read through the documentation on running pipelines"
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/44059'
      image_url: '/images/10_8/manual-pipeline-variables.png'
      description: |
        Oftentimes, we find ourselves needing to execute a single CI run with a one-time configuration value to affect behavior that will test a particular use case.
        For example, we may want to temporarily enable a specific deployment strategy, or to exclude a particular step when building the app.

        GitLab 10.8 now offers the ability to specify single-use variables when running a pipeline manually.
        You don't have to change the variables for the entire project to affect a single execution,
        and this makes it very easy to perform non-standard tests with your configuration, keeping it even more flexible.

    - name: Merge commit in merge request widget
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/merge_requests/'
      documentation_text: "Read through the documentation on merge requests"
      image_url: '/images/10_8/merge-commit-sha.png'
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/43557'
      description: | # supports markdown
        We continually strive to improve the GitLab user experience in small ways that have big impact. This particular feature
        is a great example. If your project is configured to use merge commits, a merge commit link will now appear in the widget
        of a merge request after it has been merged. Click on the link to navigate to the merge commit itself.

        In many workflows, it's helpful to navigate directly to the merge commit. For example, some teams extract these merge commits and
        put them in release branches or tags for testing and or production deploy. With this change, you can now quickly know if a merge request's work
        is part of a branch targeted to be deployed.

    - name: System note for adding issue weight
      available_in: [starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/issues/issue_weight.html'
      documentation_text: "Read through the documentation on Issue Weights"
      image_url: '/images/10_8/weight-system-note.png'
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/1481'
      description: | # supports markdown
        Issue weights allow you to associate a numerical weighting value to issues in GitLab.
        In particular, teams use it to indicate story points in Agile or Agile-based workflows. With this release,
        we are including a system note in an issue every time you add or change a weight value. This is useful for
        team members to track changes in estimated effort, or to simply know when the estimate was first logged.

    - name: Issue weight and locked status in CSV export
      available_in: [starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/issues/csv_export.html'
      documentation_text: "Read through the documentation on CSV Export"
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/2172'
      description: | # supports markdown
        In this release, we've added the issue weight and locked status of issues as part of the CSV
        export functionality. This gives you even more insight into your issues so that you can
        perform any type of custom analysis and workflows outside of GitLab.

    - name: GitLab merge requests in Jira Development Panel
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/integration/jira_development_panel.html'
      documentation_text: "Read through the documentation on GitLab Jira Development Panel Integration"
      image_url: '/images/10_8/jira-dev-panel-merge-requests.png'
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/2646'
      description: | # supports markdown
        We've improved the Jira Development Panel integration in this release to include GitLab merge requests.
        This means that if you use this specific [integration feature](https://docs.gitlab.com/ee/integration/jira_development_panel.html),
        you will see GitLab merge requests in the side panel of a linked Jira issue, in addition to GitLab commits and branches from before.

        Note that in the Jira UI, these will be called "pull requests."

    - name: Epic email notifications
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/group/epics/'
      documentation_text: "Read through the documentation on epics"
      image_url: '/images/10_8/epic-email-notification.png'
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/5480'
      description: | # supports markdown
        In the last release, we introduced the comment thread to epics. With this release, we're making collaboration in epics even more in line with the
        rest of the GitLab experience with email notifications. Just like issues and merge requests, you will receive email notifications (per your personal
        GitLab settings) in response to activity in an epic. For example, when a team member @-mentions you in an epic description or comment, you will
        receive an email notification if you have configured your notifications to that epic's group to be at Participate or higher.

    - name: Improved display of long commit messages
      available_in: [core, starter, premium, ultimate]
      image_url: '/images/10_8/long_commit.png'
      reporter: jramsay
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/41283'
      description: |
        Writing a good commit message that explains why the change was needed
        helps you make small, atomic commits and makes it easier for
        contributors to read the commit log. We've improved the formatting of
        long commit messages so that great commit messages are great to read in
        GitLab!

    - name: Embedded Snippets support
      available_in: [core, starter, premium, ultimate]
      reporter: jeremy_
      documentation_link: 'https://docs.gitlab.com/ee/user/snippets.html#embedded-snippets'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/8088'
      description: |
        Snippets are useful for starting a conversation about a piece of code,
        and you can now embed public Snippets on a website. This is perfect for
        documentation, supplementing a blog post with a code example, or a personal site.
        Thank you [Haseeb](https://gitlab.com/haseebeqx) for your contribution!

    - name: Project languages API
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/api/projects.html#languages'
      documentation_text: "Read through the documentation on Projects API"
      reporter: jramsay
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/40236'
      description: |
        Using the new Languages API you can now retrieve project language
        statistics for reporting or research, like understanding which
        programming languages are being used by your organization or by open
        source projects hosted on GitLab.com. Thank you
        [Roger](https://gitlab.com/rroger) for your contribution!

    - name: GitLab Runners for groups
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/ci/runners/#shared-specific-and-group-runners'
      documentation_text: "Read through the documentation on configuring GitLab Runners"
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/10244'
      image_url: '/images/10_8/group-runners.png'
      description: |
        GitLab Runners had two ways of configuration: either for the entire instance (shared) or at the project level (specific).
        Sometimes, however, there is a need to provide a set of Runners to an entire group of projects, but without making them accessible
        to anyone outside. On GitLab.com, for example, this fits well with the strict relationship between groups and organizations.

        Starting in GitLab 10.8, you can connect your own GitLab Runners to a specific group so each of its projects will have CI/CD
        capabilities without any further configuration. New projects will also benefit from the group's Runners as soon as they
        are created. Thank you [Alexis](https://gitlab.com/koffeinfrei) for your contribution!

    - name: Staging environment policy support for Auto DevOps
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/topics/autodevops/#deploy-policy-for-staging-and-production-environments'
      documentation_text: "Read through the documentation on Auto DevOps deployment policies"
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/38549'
      image_url: '/images/10_8/autodevops-staging.png'
      description: |
        Currently, the Auto DevOps feature uses a continuous deployment model by pushing to the `production` environment automatically
        every time a new pipeline runs on your `master` branch. This is very useful, but sometimes the maturity of the application or
        the importance of having a production environment available requires that a staging environment must be used. Only after
        checks pass there, a manual deployment to production can be done. This behavior was already supported in the Auto DevOps
        template, but not enabled by default, and required users to explicitly create a `.gitlab-ci.yml` file if they wanted to benefit
        from this feature.

        Starting in GitLab 10.8, Auto DevOps templates allow users to enable `staging` using an environment variable. You can set
        `STAGING_ENABLED` for the entire group, a single project or even for a specific run. This automatically turns
        deployment to `production` to be a manual action that can be executed at the right time.

    - name: Project templates now work with Auto DevOps
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/gitlab-basics/create-project.html'
      documentation_text: "Read through the documentation on creating project-based templates"
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/36762'
      image_url: '/images/10_8/project-template-autodevops.png'
      description: |
        GitLab provides an easy way to get started with language-specific projects by using templates. Leveraging project templates
        allows you to quickly get a new application up and running, and then customize it to better fit your specific needs.

        GitLab 10.8 now includes an improved version of the Rails, Spring, and Express templates to make full use of
        [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) features when creating new projects. You can go from idea
        to production in mere minutes by take advantage of these enhanced templates.

    - name: Geo improvements
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/administration/geo/replication/configuration.html'
      documentation_text: "Read through the documentation on Geo"
      reporter: stanhu
      description: |
        * Geo ships with Git 2.16.3, which significantly improves sync time for repositories with large number of references.
        * A Geo secondary will now initiate a pack after an initial repository clone and regular housekeeping for improved performance.
        * When repository checks are enabled, Geo will periodically run `git fsck` on each repository on the secondary.
        * Geo Prometheus metrics have been improved to make it easier to tell that repositories that have a mismatched checksum.

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

        * [Resolve a bug with "OffPeakPeriods" where timezone is set inside of `gitlab/gitlab-runner` image](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/897)
        * [Add new metrics related to jobs requesting and API usage](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/886)
        * [Add support for fedora/27 and fedora/28 packages](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/883)
        * [Update supported distribution releases](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/887)
        * [Change docs license to CC BY-SA 4.0](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/893)

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

# Omnibus and performance

    - name: Omnibus improvements
      available_in: [core, starter, premium, ultimate]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/omnibus/'
      documentation_text: 'Read through the documentation on Omnibus GitLab'
      reporter: joshlambert
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/12345'
      description: |
        - GitLab 10.8 includes [Mattermost 4.9](https://about.mattermost.com/releases/mattermost-4-9/), an [open source Slack alternative](https://about.mattermost.com/) whose newest release includes muted channels, team icons, plus much more.
        - HTTP compression is [now enabled by default](https://docs.gitlab.com/omnibus/settings/nginx.html#disabling-gzip-compression), improving responsiveness and reducing bandwidth consumption. To disable, set `nginx['gzip_enabled'] = false`.
        - GitLab [Mattermost 4.9.1](https://docs.mattermost.com/administration/changelog.html#release-v4-9) contains fixes for performance regressions and issues with the new permissions system.
        - `ruby` has been updated to 2.3.7, `rubygems` has been updated to 2.6.14
        - `git` has been updated to 2.16.3, `openssl` has been updated to 1.0.2o
        - `libxslt` has been updated to 1.1.32, `libxml2` has been updated to 2.9.8, `rsync` has been updated to 3.1.3, `curl` has been updated to 7.59.0
        - `unzip` and `bzip2` have been patched to address low impact CVE's
        - Going forward, GitLab packages will check for removed configuration settings before upgrade, requiring users to update the settings first before proceeding
        - Prometheus [AlertManager](https://prometheus.io/docs/alerting/alertmanager/) bundled, off by default, to support upcoming proactive notifications
        - The GitLab artwork that is output during `reconfigure` is now yellow, instead of red

    - name: Performance improvements
      available_in: [core, starter, premium, ultimate]
      performance_url: https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&label_name%5B%5D=performance&milestone_title=10.8 # Link to the merged MRs in the corresponding milestone
      documentation_text:  See all the performance improvements in GitLab 10.8
      reporter: various
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/12345'
      description: |
        Some of the more noteworthy performance improvements in GitLab 10.8
        include:

        * [Diff notes will now load faster](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18657)
        * [Calls related to processing notifications are done asynchronously](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18535)
        * [Branches are loaded asynchronously when creating a new merge request](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18315)

# MVP
mvp:
  fullname: Alexis Reigel
  gitlab: koffeinfrei
  description: |
    This release's MVP is Alexis Reigel. Alexis added a stellar contribution in the form of [CI runners shared within groups](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9646), a highly requested feature. After over a year of perserverance and a ton of collaboration, Alexis' contribution makes it worlds easier to manage runners for projects in groups.

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

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

# UPGRADE BAROMETER
barometer:
  reporter: mayra_cabrera
  description: |
    To upgrade to GitLab 10.8 from the latest 10.7 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).

    For this release we have migrations, post-deploy migrations, and to help with the larger migrations we have introduced background migrations.

    GitLab.com migrations took approximately 10 minutes and post-deploy migrations amounted for a total of around two minutes. Background migrations on the other hand are sidekiq jobs that will run synchronously, for this release these migrations took less than a day to complete, no side effects were expected nor present; these target older pipeline builds so newer executed pipelines are not affected.

    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: API v3
    due: GitLab 11.0.
    reporter: jeremy_
    description: |
      API v4 has been the preferred version of the GitLab API since 9.0. With GitLab 11.0, API v3 will be removed and no longer supported.

  - feature_name: Mattermost configuration changes
    due: GitLab 11.0.
    reporter: joshlambert
    description: |
      With the release of GitLab 11.0, Mattermost configuration is being simplifed. The core settings necessary to run Mattermost and integrate with GitLab will continue to be set `gitlab.rb`, however the rest must now be configured in the Mattermost System Console.

      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: Support for DSA SSH keys
    due: GitLab 11.0.
    reporter: jeremy_
    description: |
      Due to published weakness in the ssh-dss algorithm, we'll begin [winding down support for DSA SSH keys](https://gitlab.com/gitlab-org/gitlab-ce/issues/44364).
      In the iteration planned for 11.0, we plan to continue allowing existing DSA keys – but prevent new keys from being added to GitLab.com. We'll prevent this by default for self-hosted instances, but allow instance admins to override this setting.

      In a future release, we'll reject DSA keys for all GitLab instances.

  - feature_name: Debian 7 Wheezy Support
    due: GitLab 11.0.
    reporter: joshlambert
    description: |
      GitLab 11.0 will be 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: Dynamically generated milestone pages
    due: GitLab 11.2
    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).
