features:
# TOP FEATURE
  top:
    - name: Configurable Issue Boards
      available_in: [starter, premium, ultimate]
      documentation_link:  'https://docs.gitlab.com/ee/user/project/issue_board.html#board-with-configuration'
      documentation_text: 'Read through the documentation on configuring Issue Boards'
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/2518'
      description: |
        Many teams share an issue board to plan and track their work, and so they want the board
        to reflect the same set of issues seen by anyone on the team. Previously, you
        were only able to associate a milestone with an issue board. With this
        release, both project boards and group boards are entirely configurable, so that
        you can associate a board with a milestone (including the `No Milestone` choice),
        multiple labels, an assignee, and a weight, providing many more flexible possibilities
        for your team.

        This configuration is saved with the board itself, so that anyone who visits the board will
        see that it already has these filters pre-applied. You view and edit this configuration
        by clicking the `View scope` or `Edit board` button (depending on your
        [user permissions](https://docs.gitlab.com/ee/user/permissions.html)).

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

# PRIMARY FEATURES
  primary:
    - name: One-click install for Helm and Ingress on Kubernetes
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/clusters/index.html#installing-applications'
      documentation_text: "Read through the documentation on installing applications on GKE clusters"
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/38464'
      image_url: '/images/10_2/cluster_apps.png'
      description: |
        Starting with GitLab 10.1 you can easily connect your Google account to your projects and
        create a new [Kubernetes cluster](https://docs.gitlab.com/ee/user/project/clusters/)
        directly from the GitLab **Cluster** page. Then you can use it to host
        [Review Apps](https://about.gitlab.com/product/review-apps/) and deployment environments.

        In GitLab 10.2 we go even further, allowing you to install
        [Helm Tiller](https://docs.helm.sh/) and [Nginx Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)
        with one click into your GKE cluster, reducing the time before you can go live with
        your applications.

    - name: Commit Author Restriction
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/push_rules/push_rules.html'
      documentation_text: "Read through the documentation on Push Rules"
      image_url: '/images/10_2/author_restrictions.png'
      reporter: mydigitalself
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/2445'
      description: |
        [GitLab Enterprise Edition Premium](/pricing/) provides additional levels of control to
        your workflow to ensure that strict policies can be enforced within your
        development environment.

        With Commit Author Restriction, it is now possible to ensure that the committer
        is the same user pushing changes back to the repository. This can prevent
        unauthorized code entering your codebase or enforce tightly controlled developer
        workflows.

        You can choose to apply this setting to individual repositories, or across the
        entire GitLab instance to enforce server-wide control.

        Used in conjunction with EEP's ability to [reject unsigned commits](/blog/2017/10/22/gitlab-10-1-released/#reject-unsigned-commits)
        you can now be in complete control of identity and verification when changes
        are applied to your repositories in GitLab.

    - name: GitLab Geo is now Generally Available
      available_in: [premium, ultimate]
      gitlab_com: false
      documentation_link: https://docs.gitlab.com/ee/gitlab-geo/README.html
      documentation_text: 'Read through the documentation on GitLab Geo'
      image_url: '/images/10_2/geo_nodes.png'
      reporter: jramsay
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/12345'
      description: |
        Many teams who use GitLab are geographically spread out, but your
        GitLab instance is in a single location. GitLab Geo brings GitLab
        closer to your team, making fetch operations like cloning repositories
        faster.

        GitLab Geo is now generally available! When configured, GitLab Geo
        keeps read-only secondaries in sync with your primary GitLab instance.
        You can use GitLab Geo to access Git, LFS objects, issues, wikis, and
        CI artifacts from the closest GitLab instance.

        **Note**: while Geo and High Availability are now each individually GA,
        use of GitLab Geo in combination with High Availability, is considered *Beta*.

        Notable changes shipped with GitLab 10.2:

          - Added [HTTPS Git replication support](https://gitlab.com/gitlab-org/gitlab-ee/issues/3341)
          - Added [secure PostgreSQL replication](https://docs.gitlab.com/ee/gitlab-geo/updating_the_geo_nodes.html#secure-postgresql-replication)
          - Added [API to retrieve geo status](https://gitlab.com/gitlab-org/gitlab-ee/issues/3740)
          - Improved handling of replication errors

        See full the [list of changes for Geo on 10.2](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&label_name[]=Geo&milestone_title=10.2)

    - name: Postgres HA is now Generally Available
      available_in: [premium, ultimate]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/ee/administration/high_availability/database.html'
      documentation_text: 'Read through the documentation on configuring a database for GitLab HA'
      reporter: joshlambert
      mr_url: 'https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1987'
      image_url: '/images/10_2/postgres_ha.png'
      description: |
        For many organizations, GitLab is a critical component of their software engineering
        tool chain, powering not only their code repository but also CI/CD, issue management,
        and much more. To ensure GitLab is available around the clock it can be deployed in a
        [highly available configuration](/solutions/high-availability/), providing additional redundancy
        and scale.

        With GitLab 10.2, we are proud to announce that PostgreSQL High Availability is now
        generally available. As part of GitLab Enterprise Edition Premium, the Omnibus
        installation package makes [setting up a production Postgres database cluster](https://docs.gitlab.com/ee/administration/high_availability/database.html) easy.

        In the event a database node goes down, the cluster will automatically fail over
        ensuring your developers flow isn't interrupted.

# SECONDARY FEATURES
  secondary:
    - name: Compare production and canary performance
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/integrations/prometheus_library/kubernetes.html#displaying-canary-metrics'
      documentation_text: 'Read through the documentation on Canary System Monitoring'
      reporter: joshlambert
      mr_url: 'https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15201'
      image_url: '/images/10_2/canary_monitoring.png'
      description: |
        In GitLab 9.1, we introduced [canary deployments](https://docs.gitlab.com/ee/user/project/canary_deployments.html)
        to GitLab CI, enabling organizations to easily release software in a more controlled
        fashion. A new version can be deployed to a small percentage of your app nodes,
        allowing real-world usage by a subset of users prior to full deployment.

        With GitLab 10.2, we have added the ability to track the system metrics of the
        canary version, allowing easy comparison of the real-world performance between
        versions. Developers can quickly determine whether a change had a positive or
        negative impact on performance, and decide whether to proceed with the broader
        deployment. The best part is that they can do all of this without leaving GitLab!

    - name: Improved Audit Events
      available_in: [starter, premium, ultimate]
      gitlab_com: false
      documentation_link:  https://docs.gitlab.com/ee/administration/audit_events.html
      documentation_text: "Read through the documentation on Audit Events"
      reporter: mydigitalself
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/1371'
      description: |
        GitLab Enterprise Edition enhances control and accountability with Audit Events.
        With GitLab Enterprise Edition Starter (EES) you can view audit events in each
        project or group. GitLab Enterprise Edition Premium (EEP) includes a
        centralised audit log where all project events are collated in a single place.

        GitLab 10.2 EES & EEP now include additional events for actions taken on projects
        and groups, including:

          - Project or group created
          - Project or group deleted
          - Project moved, renamed or transferred
          - Group visibility changed
          - User added to group, including permission level of user
          - User permission changed
          - Project added or removed from a group

        In GitLab EEP, deleted project and group audit data is now persisted in the server-wide
        audit log available in the admin area. The IP address of the user performing the action
        is now also included.

    - name: Subgroups and projects on the group page
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/group/subgroups/index.html'
      documentation_text: "Read through the documentation on Subgroups"
      image_url: '/images/10_2/subgroups_tree.png'
      reporter: mydigitalself
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/30343'
      description: |
        Subgroups are a great way to organise projects or teams on GitLab. With nearly
        unlimited nesting of groups, you can create structures to reflect complex repositories,
        microservices, or even how your internal development teams are structured.

        GitLab's group page has now been given an overhaul to better navigate and explore
        subgroups and projects. You will now see an expandable tree navigation on the group
        page, allowing you to quickly find what you're looking for or discover new projects and groups.

    - name: Epics
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/group/epics/'
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/3254'
      image_url: '/images/10_2/epics.png'
      description: |
        With this release, we are launching a very early version of _Epics_ as the first feature of [Portfolio Management](https://gitlab.com/gitlab-org/gitlab-ee/issues/3254). Epics are
        designed to enable you to plan and track your work at the feature level,
        as opposed to the design and implementation details level of an issue.

        Epics are scoped at the group level. After creating an epic with a title,
        and optionally writing its description, you can then create and link
        multiple issues with the epic. This is a typical top-down workflow where you
        plan a high-level feature idea, and then break it down into smaller issues
        to be implemented. Conversely, you can take a bottom-up approach where you take
        multiple existing issues that are related and link to them together in
        a new epic.

        For a given epic, any issue belonging to a project in the epic's group or any
        of the epic's subgroups can be linked. An epic also has optional
        _planned start date_ and _planned end date_.

        Epics are included in [Enterprise Edition Ultimate (EEU)](/product/) and the [Gold plan of GitLab.com](/pricing#gitlab-com).

    - name: Personal Access Tokens replacing Private Access Tokens
      available_in: [core, starter, premium, ultimate]
      documentation_text: 'Read through the documentation on Personal Access Tokens'
      documentation_link: 'https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html'
      reporter: mydigitalself
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/38595'
      description: |
        Personal Access Tokens can be scoped to certain API privileges, thus providing
        better security when accessing GitLab through the API or third-party applications.

        Private Tokens were previously deprecated and have now been completely removed.

        All Private Tokens will be migrated to Personal Access Tokens during upgrade, ensuring
        your existing applications continue to function.

    - name: Promote project milestones to group milestones
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/milestones/#milestone-promotion'
      documentation_text: 'Read through the documentation on promoting milestones'
      reporter: victorwu
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/38777'
      image_url: '/images/10_2/promote_milestone.png'
      description: |
        When you've outgrown your project, you can easily promote project milestones
        to group milestones. Simply click the button from the desired project milestone page
        to promote it to a group milestone. Similar to label promotion, all project milestones with that same title
        across all projects in the group will be merged together into one group milestone. And all
        issues and merge requests that previously had any of those project milestones
        will now automatically have the new group milestone. Project issue
        boards associated with the previous project milestone are now associated with the promoted
        group milestone.

    - name: Restrict push repository mirroring to admins
      available_in: [starter, premium, ultimate]
      gitlab_com: false #please check
      documentation_link: 'https://docs.gitlab.com/ee/user/project/repository/repository_mirroring.html'
      documentation_text: 'Read through the documentation on Repository Mirroring'
      reporter: jramsay
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/1144'
      description: |
        Push mirroring, when enabled for a repository, will automatically mirror
        it to the configured target Git repository.

        Admins can now limit access to push mirroring to only admin users to
        prevent private projects from being automatically mirrored to another
        repository that could be external and unsecured.

    - name: Restore project readme view
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/profile/preferences.html'
      documentation_text: 'Read through the documentation on User Preferences'
      reporter: jramsay
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/30140'
      description: |
        Your preferred project home page settings allow you to choose the
        content you want to see on every project's home page. You can choose
        between the projects activity, file list and readme, and readme only.

        In GitLab 9.0 the readme only option was removed, but has now been
        restored for those who prefer a minimal project overview.

    - name: Improved internationalization
      available_in: [core, starter, premium, ultimate]
      #gitlab_com: false #please check
      documentation_link: 'https://docs.gitlab.com/ee/development/i18n/index.html'
      documentation_text: 'Read through the documentation on translating GitLab'
      reporter: jramsay
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/4012'
      description: |
        As part of our ongoing effort to internationalize GitLab, we have now
        externalised strings in the Contributors and Tag pages, allowing our
        translation community to add more languages and strings to GitLab.

        If you are interested in contributing to GitLab's Internationalization
        efforts, we welcome you to join our
        [translation community](https://docs.gitlab.com/ee/development/i18n/index.html).

    - name: API for GitLab Pages
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/api/pages_domains.html'
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/23000'
      description: |
        [GitLab Pages](https://about.gitlab.com/product/pages/) allow you to publish a static website
        directly from your project's pipeline. If you want to make it more professional, you can also
        define custom domains for your content, and protect them with certificates.

        In GitLab 10.2, the management of custom domains for GitLab Pages is available via API calls,
        so that you can automate adding new domains, getting information for existing ones, and also updating
        domain information, for example, when your SSL certificate has been renewed.

    - name: Project visibility as a CI/CD variable
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/ci/variables/#predefined-variables-environment-variables'
      documentation_text: 'Read through the documentation containing all available predefined variables'
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/37473'
      description: |
        In GitLab, you can define if you want to create a public project, or if you prefer to keep it private.
        When dealing with pipelines, sometimes you need this information so you can take different actions.

        This information is now available in GitLab 10.2, and reading the `CI_PROJECT_VISIBILITY` variable
        you can define, for example, if public access to artifacts and Docker images for the project are allowed.
        Very useful in case you have a shared template that applies to multiple different projects.

    - name: Omnibus improvements
      available_in: [core, starter, premium, ultimate]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/omnibus/README.html'
      documentation_text: 'Read through the documentation on Omnibus GitLab'
      reporter: joshlambert
      description: |
        * Warnings are now clearly displayed when deprecated configuration settings are used.
        * Support has been added for [running separate Redis instances](https://docs.gitlab.com/omnibus/settings/redis.html#running-with-multiple-redis-instances) for each persistence class.
        * OpenSSL has been updated to 1.0.2m.
        * libxml2 has been updated to 2.9.6.

    - name: GitLab Mattermost 4.3.2
      available_in: [core, starter, premium, ultimate]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/omnibus/gitlab-mattermost/'
      documentation_text: "Read through the documentation on GitLab Mattermost"
      reporter: victorwu
      description: |
        GitLab 10.2 includes [Mattermost 4.3.2](https://about.mattermost.com/blog/mattermost-4-3/),
        an [open source Slack alternative](https://about.mattermost.com) whose
        newest release includes a beta support for tablet computers, mobile
        appenhancements, plus much more. This version includes [security updates](http://about.mattermost.com/security-updates/)
        and an upgrade is recommended.

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

          * [Upgraded minio library](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/707): support Amazon S3 Accelerated endpoints and `eu-west-2` region
          * Added [`helper_image` option to docker executor config](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/723)

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

    - 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.2
      documentation_text: 'Check all performance improvements shipped with GitLab 10.2'
      reporter: joshlambert
      issue_url: 'https://gitlab.com/groups/gitlab-org/issues?scope=all&utf8=%E2%9C%93&state=closed&label_name[]=performance&milestone_title=10.2'
      description: |
        Performance is an important part of GitLab, allowing GitLab to scale to hundreds of
        thousands of users.

        GitLab 10.2 introduces a new GitHub importer that uses Sidekiq to perform
        its work in parallel, vastly reducing the time spent importing projects from
        GitHub. In the event of hitting the GitHub rate limit the new importer will
        suspend work and resume it once the rate limit has been reset, without blocking
        any Sidekiq workers from performing other work.

        For small projects such as <https://github.com/yorickpeterse/oga> the import
        time was reduced from 5 minutes to 30-60 seconds, while for larger projects
        such as <https://github.com/kubernetes/kubernetes> the import time was reduced
        from several weeks to 6.5 hours.

        For more information on the new GitHub importer, you can check out the [CE merge request for these changes](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/14731).

        GitLab 10.2 also includes other 12 performance improvements, with a particular focus on speeding
        up the load speed of merge requests. We have also made improvements to issue load
        times, as well as reducing some edge cases which can consume significant
        server resources.

# MVP
mvp:
  fullname: Travis Miller
  gitlab: travismiller
  description: |
    Travis has been working to improve GitLab Pages over the past few releases,
    and with GitLab 10.2 he has contributed to a [new Pages API to manage existing domains](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/13917).
    This provides the ability to programmatically manage key tasks, like updating an
    expiring certificate or converting an existing domain to HTTPS.

    Thanks Travis for all the hard work! We sent GitLab socks, stickers, a shirt, and a pint glass, which he seems to be making good use of!
  image: '/images/10_2/mvp_gift.jpg'

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

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

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

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

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

# DEPRECATIONS (optional)
deprecations:
  - feature_name: GitLab Geo SSH Repository Sync
    due: December 22nd, 2017
    reporter: jramsay
    description: |
      HTTPS repository sync replaces SSH repository sync for GitLab Geo. SSH
      repository sync will be removed in GitLab 10.3.

      Refer to [Geo node upgrade documentation](https://docs.gitlab.com/ee/gitlab-geo/updating_the_geo_nodes.html#https-repository-sync)
      to enable HTTPS repository sync.

  - feature_name: 'The <code>gitlab</code> Helm chart'
    due: December 22nd, 2017
    reporter: joshlambert
    description: |
      The [`gitlab` Helm chart](https://docs.gitlab.com/ee/install/kubernetes/gitlab_chart.html)
      is deprecated, and will be replaced by the new
      [cloud native GitLab chart](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/2420).
       We are planning for an initial beta release of this new chart in 10.3.

      A migration will be required to move from the current deprecated chart,
      to the new cloud native GitLab chart.
  - feature_name: Mattermost configuration changes
    due: GitLab 11.0
    reporter: joshlambert
    description: |
      With the release of GitLab 11.0, the number of Mattermost configuration options supported within
      `gitlab.rb` will be reduced. We will 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. Going forward, other
      configuration settings should be set
      directly within the Mattermost console, or [passed as environment variables](http://docs.gitlab.com/omnibus/gitlab-mattermost/#upgrading-gitlab-mattermost-from-versions-prior-to-11-0).


      Presently with two applications attempting to write to the same config file, changes can be lost.
