features:
# TOP FEATURE
  top:
    - name: Static Application Security Testing (SAST)
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/application_security/sast/'
      documentation_text: "Read through the documentation on SAST"
      image_url: '/images/10_3/sast.png'
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/3723'
      description: |
        Running secure application code in production is critical;
        vulnerabilities can lead to everything from denial of service to leaked
        user information. Running security checks on a regular basis helps
        protect you from known vulnerabilities, even if they are affecting
        libraries you import in your projects.

        With GitLab 10.3, Static Application Security Testing (SAST) scans the
        code (also known as static analysis) for known security issues that
        could be exploited by malicious users, like unpatched external
        dependencies or cross-site scripting vulnerabilities. It automatically
        recognizes the most common languages (Ruby, JavaScript, and Python are
        currently supported), and a summary shows up directly in Merge Requests
        so your team is aware of potential problems before merging code into
        master and deploying it to production. Static Application Security
        Testing is also now [part of Auto
        DevOps](https://docs.gitlab.com/ee/topics/autodevops/#auto-sast) to
        provide security by default.

# PRIMARY FEATURES
  primary:
    - name: Browser Performance Testing
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/merge_requests/browser_performance_testing.html'
      image_url: '/images/10_3/browser_performance.png'
      reporter: joshlambert
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/3046'
      description: |
        GitLab offers a great way to monitor the performance of your production
        application, but it's also critical to ensure that new code doesn't
        introduce performance regressions. For example, a developer may
        incorporate a new image from design, but forget to compress it; or a new
        JavaScript library may be added to `<head>`, slowing down page load.
        Catching these regressions with only a manual review can be challenging.

        To help address this, we are introducing an easy way to analyze the
        performance impact of a merge request for web apps. Browser Performance
        Testing runs a headless browser to simulate visiting one or more pages
        of your application and analyzes them. A summary of performance changes
        is provided on the merge request so you're aware of the performance impact
        *before* merging into `master`.

    - name: Merge Request Commit Discussions
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/discussions/#commit-discussions-in-the-context-of-a-merge-request'
      reporter: victorwu
      image_url: '/images/10_3/comment_commit_mr.png'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/31847'
      description: |
        GitLab works great for workflows where teams collaborate and comment on
        each new version of a merge request.

        But some teams work at the individual commit level; they want to have
        conversations about every single commit, even within a push containing
        multiple commits. This was not possible previously.

        Today, we are shipping commit-based workflows in merge requests. Simply
        navigate to the commits tab of a merge request and click on a commit to
        bring you to the changes tab, with a new interface that allows you to
        have a resolvable discussion about a particular commit. That discussion
        is also shown in the discussion tab itself, along with other
        conversations. This feature works alongside the existing workflow,
        giving your team flexibility to select whichever flow works best. View [a
        short demo](https://about.gitlab.com/blog/2018/01/04/comment-on-commits-feature-tutorial/)
        of the new workflow.

    - name: Customize branch name when creating merge request from issue
      available_in: [core, starter, premium, ultimate]
      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 a merge request from an issue'
      reporter: victorwu
      image_url: '/images/10_3/create_merge_request_customize_branch_name.png'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/21143'
      description: |
        You can create a merge request, along with an underlying branch, right
        from an issue in one click. Clicking the create merge request button
        automatically creates a branch name based on the title of your issue.
        But in some cases you don't really want this, especially if your issue
        title is very wordy and you want the branch name to be more succinct. With
        this release, you can now customize the branch name before creation.
        This also works when creating a branch from an issue without an
        associated merge request.

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

    - name: Flow charts, sequence diagrams, and Gantt diagrams in GitLab Flavored Markdown (GFM) with Mermaid
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/markdown.html#mermaid'
      documentation_text: 'Read through the documentation on Mermaid support in GFM'
      reporter: victorwu
      image_url: '/images/10_3/mermaid_gfm.png'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/3711'
      description: |
        You can now create beautiful flow charts, sequence diagrams, and Gantt diagrams in issue / merge requests
        descriptions and comments using GitLab Flavored Markdown (GFM)
        Just follow the simple Mermaid syntax, now supported in GFM.

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

    - name: Multiple Kubernetes clusters per project (Beta)
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/clusters/#multiple-kubernetes-clusters'
      documentation_text: "Read through the documentation on Multiple Kubernetes clusters per project"
      image_url: '/images/10_3/multiple_clusters.png'
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/3734'
      description: |
        GitLab can easily deploy your application to different environments
        within a Kubernetes cluster. We commonly see Development, Staging, and
        Production, and Review Apps all published in the same way. Up until now,
        they all lived in the same cluster, but you may have the need to keep
        data and access separated, for example if regulations require you to
        store production data in a different physical location.

        With GitLab 10.3, you can configure multiple clusters for each project,
        each linked to a specific environment, so the right cluster is
        automatically used by CI/CD pipelines to publish your application.

# SECONDARY FEATURES
  secondary:

    - name: Automatically run first pipeline when enabling Auto DevOps
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/topics/autodevops/#enabling-auto-devops'
      documentation_text: "Read through the documentation on enabling Auto DevOps"
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/38962'
      description: |
        Previously in GitLab if you enabled Auto DevOps you still had to wait until
        you pushed a commit before your pipelines would populate.
        This was a confusing experience that didn't follow expected behavior.

        With GitLab 10.3, a pipeline for your project will be run as soon as you
        enable Auto DevOps in Settings, so you can immediately see results without
        needing to push another commit to your code.

    - name: Strict check on artifacts dependencies
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/ci/yaml/#when-a-dependent-job-will-fail'
      documentation_text: "Read through the documentation on strict check on artifacts dependencies"
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/34834'
      description: |
        When dealing with CI/CD pipelines, it is quite common that artifacts are
        created in one job and then used later by another job. Using the
        `dependencies` keyword, you can explicitly list which artifacts from
        previous stages you need. But when jobs are retried some time later,
        those artifacts may no longer exist, for example if they have expired or
        have been manually erased. This could lead to inconsistent states where
        code is expecting to find resources that are not available, creating
        errors that are hard to spot and debug.

        In GitLab 10.3, we introduce strict checking on these dependencies. Since
        jobs will fail if their dependencies cannot be found, you'll always be aware
        if something required is missing. This allows you to take proper actions
        to solve the problem, for example running a brand new pipeline from scratch.

    - name: Restricted deletion of CI/CD job logs
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/permissions.html#gitlab-ci-cd-permissions'
      documentation_text: "Read through the documentation on the CI/CD permissions model"
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/31771'
      description: |
        When running a job as part of a CI/CD pipeline, the job log is stored in
        GitLab and is available for further analysis to users that have access
        to the project. It can be also erased in order to avoid information
        leaks or to free up space.

        With GitLab 10.3, only Masters and the user that triggered the job are
        authorized to erase the job logs; enforcing a more consistent permission
        model.

    - name: Improved integration with existing clusters (Beta)
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/clusters/'
      documentation_text: "Read through the documentation on cluster integration"
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/35616'
      description: |
        Until now, configuring a project to use an existing Kubernetes cluster
        (as opposed to creating a new cluster) relied on the service integration
        page in the project settings. This made the flow inconsistent with the
        first-class support for Clusters introduced in GitLab 10.1.

        GitLab 10.3 adds the ability to add existing Kubernetes clusters to a
        project, directly from the Clusters page, and deprecates the old service
        integration page.

    - name: Git push and pull on project redirects
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/#redirects-when-changing-repository-paths'
      documentation_text: "Learn how redirects work when the repository path changes"
      reporter: mydigitalself
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/35385'
      description: | # supports markdown
        Renaming and moving projects happens all the time. GitLab's web user
        interface has always redirected people from the old location to the new
        location, but the same has not been true for Git actions.

        From GitLab 10.3, Git actions will now redirect too! This means that any
        build scripts, automation, or Git clients will continue to work after a
        user or group rename, making any transition a lot smoother.

        Please note, to avoid pulling from or pushing to an entirely incorrect
        repository, the old path will be reserved.

    - name: Show project member role on list of projects
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/permissions.html'
      documentation_text: "Read through the documentation on GitLab user roles and permissions"
      image_url: '/images/10_3/role_labels.png'
      reporter: mydigitalself
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/27742'
      description: |
        When working with multiple projects, sometimes it's difficult to remember what
        permissions you have for each project. This can lead to frustrating situations and
        not knowing why certain features aren't available.

        Having a quick reference that tells you what permission level you have helps you understand
        your limitations and lets you act within them or request escalated privileges when appropriate.

        Now you can see your permission level on the GitLab Project Dashboard next
        to the project name. You no longer have to click into each project and
        dig into the users page to find this info.

    - name: 'Customize "New Project" page'
      available_in: [core, starter, premium, ultimate]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/ee/customization/new_project_page.html'
      documentation_text: 'Read through the documentation on customizing the "New project" page'
      image_url: '/images/10_3/custom_new_project_page.png'
      reporter: mydigitalself
      mr_url: 'https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15541'
      description: |
        With thanks to our community contributor, [Markus
        Koller](https://gitlab.com/toupeira), it is now possible for GitLab
        administrators to add your own help text on the "New Project" page.

        This is a great way to provide additional instruction to users on how
        projects should be created. As this text supports Markdown, you can link
        to any further pages or documentation to provide additional help.

    - name: User and group additions to Protected Branch API
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/api/protected_branches.html'
      documentation_text: "Read through the documentation on Protected Branches API"
      reporter: mydigitalself
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/27742'
      description: |
        [Protected
        branches](https://docs.gitlab.com/ee/user/project/protected_branches.html)
        allow you to lock down push or merge access to your repository's
        branches, preventing inadvertent changes entering your code or enforcing
        particular workflows.

        One great feature of protected branches is to specify users or groups
        that do have permission to push or merge changes. This is now available
        in the API.

    - name: Navigate to epic from issue
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/group/epics/'
      documentation_text: 'Read through the documentation on Epics'
      reporter: victorwu
      image_url: '/images/10_3/issue-containing-epic.png'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/3696'
      description: |
        Since issues can only belong to one epic, when looking at an issue it's useful to know if
        it already belongs to an epic. The containing epic of an issue now appears in the issue
        sidebar as a link, allowing you to quickly navigate to it.

    - name: Attach images to epics
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/group/epics/'
      documentation_text: 'Read through the documentation on Epics'
      reporter: victorwu
      image_url: '/images/10_3/epics-attachments.png'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/3938'
      description: |
        You can now attach images (or any file) to an epic, via the epic
        description, just like in an issue description (and other Markdown
        boxes in GitLab). This allows you to be even more descriptive in
        documenting epics, such as by including inline wireframes and mockups.

    - name: Render links to epics in GitLab Flavored Markdown (GFM)
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/markdown.html#special-gitlab-references'
      documentation_text: 'Read through the documentation on GFM Special GitLab References'
      reporter: victorwu
      image_url: '/images/10_3/reference_epics.png'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/3853'
      description: |
        Links to epics in GitLab Flavored Markdown (GFM) textboxes will now be
        rendered similar to issues, merge requests, and other objects in GitLab.
        The group path is shown followed by `&`, and then the epic ID. A helpful
        tooltip shows the epic title. This allows you to paste a link to an epic
        in a textbox, and GitLab will render it more compactly and in a more readable fashion.
        You can also directly enter the shorthand for the epic reference in the GFM field, such as
        `gitlab-org&23`, and GitLab will turn that into link.

    - name: Update issue weight from Issue Board sidebar
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/issue_board.html'
      documentation_text: 'Read through the documentation on Issue Boards'
      reporter: victorwu
      image_url: '/images/10_3/board_sidebar_weight.png'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/1379'
      description: | # supports markdown
        You are now able to update an issue's weight right from an issue board's
        sidebar, exactly the same as in the issue page itself. This allows you to
        quickly and more fully manage issues when doing planning and tracking
        from within a board.

    - name: Sort milestones on group milestone list
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/milestones/#creating-a-group-milestone'
      documentation_text: 'Read through the documentation on Group Milestones'
      reporter: victorwu
      image_url: '/images/10_3/group_milestone_list_sort.png'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/39720'
      description: |
        You are now able to sort milestones on the group milestone list page,
        similar to the project milestones list page. We introduced group
        milestones a few releases ago and are working to bring features from
        project milestones to group milestones.

        Thank you [George Andrinopoulos](https://gitlab.com/geoandri) for the contribution!

    - name: Redesigned merge request diff file navigation
      available_in: [core, starter, premium, ultimate] # required
      documentation_link: 'https://docs.gitlab.com/ee/user/project/merge_requests/#merge-request-diff-file-navigation'
      documentation_text: 'Read through the documentation on merge request diff file navigation'
      reporter: victorwu
      image_url: '/images/10_3/merge_request_file_nav_dropdown.png'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/36687'
      description: | # supports markdown
        The merge request diff file navigation has been redesigned to more
        clearly show the file name in its own line. The file path is also now
        truncated at the start if it is too long.

    - name: Smarter autocomplete for label quick action
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/quick_actions.html'
      documentation_text: 'Read through the documentation on Quick Actions'
      reporter: victorwu
      image_url: '/images/10_3/labels_quick_action.png'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/22680'
      description: | # supports markdown
        When using quick actions to add or remove labels to an issue or merge
        request, the autocomplete dropdown is extremely helpful to quickly find
        what you are looking for. With the latest change, autocomplete is even
        smarter so that when adding a label, the dropdown _doesn't_ show labels
        that are already added. And when removing a label, the dropdown _only_
        shows labels that are already added.

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

    - name: Create merge request through email
      available_in: [core, starter, premium, ultimate] # required
      documentation_link: 'https://docs.gitlab.com/ee/user/project/merge_requests/#create-new-merge-requests-by-email'
      documentation_text: 'Read through the documentation on creating merge requests through email'
      reporter: victorwu
      image_url: '/images/10_3/create_merge_request_from_email.png'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/32878'
      description: |
        Some people prefer doing development as much as possible using their desktop
        tools, reserving their use of the GitLab web interface for tasks which are
        absolutely necessary there.

        With today's release, you can now create merge requests through email, expanding
        the breadth of developer-focused features you can use with your existing tools.
        Send an email to GitLab, specifying the source branch name in the email subject
        line, and GitLab will automatically create the merge request for you. Find the
        special (and unique-to-you) email address for a given project by clicking the link
        at the bottom of the project merge requests page. It doesn't change (unless you refresh it).
        So you can safely save it in your email client.

        For developers who do development, Git, and email all inside a terminal, you can now
        do everything up to creating a merge request all without leaving that terminal.

    - name: Total issue time spent in milestone
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/milestones/#milestone-sidebar' # not available in /ee/ yet
      documentation_text: 'Read through the documentation on the milestones sidebar'
      reporter: victorwu
      image_url: '/images/10_3/milestone-sidebar.png'
      image_noshadow: true
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/39335'
      description: |
        Many teams track how much time is spent working individually on issues.
        With this latest change, you can now see how much time is spent on all
        of the issues in a single milestone, summed up together, in the sidebar
        of the milestone page.

        Thank you [George Andrinopoulos](https://gitlab.com/geoandri) for the
        contribution!

    - name: Only mirror protected branches
      available_in: [starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/repository/repository_mirroring.html#push-only-protected-branches-core'
      documentation_text: "Read through the documentation on Repository Mirroring"
      reporter: jramsay
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/3843'
      description: |
        Pull and push mirroring, when enabled for a repository, will
        automatically mirror to and from the configured target Git repository.
        But this fails if any pushes contain altered Git history, such as by
        rebasing. It's normally not a good idea to rebase certain key branches,
        like `master`, but it's more common for feature branches.

        To prevent rewritten history from a feature branch causing mirroring to
        fail, mirroring can now be limited to only protected branches.

    - name: Trigger pull mirroring via API
      available_in: [starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/repository/repository_mirroring.html#trigger-update-using-api'
      documentation_text: "Read through the documentation on triggering pull mirroring via API"
      reporter: jramsay
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/3821'
      description: |
        Pull mirroring, when enabled for a repository, automatically mirrors
        changes from the configured upstream Git repository to your repository.
        Changes are mirrored regularly when they are detected by polling.

        A new API has been added to trigger changes to be pulled immediately.
        When used with a push event webhook from the upstream repository, pull
        mirroring can happen within seconds.

    - name: Immediate push mirroring
      available_in: [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 Repository Mirroring"
      reporter: jramsay
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/3832'
      description: |
        Push mirroring, when enabled for a repository, will automatically
        push changes to the configured downstream Git repository.

        The rate limit has been updated to push changes immediately, but is
        limited to one push every five minutes. If mirroring is limited to
        protected branches, the rate limit is decreased to one push every
        minute.

    - name: Restrict 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/3730'
      description: |
        Push and pull mirroring, when enabled for a repository, will
        automatically mirror to or from the configured target Git repository.

        In GitLab 10.3 push mirroring can be restricted to admins. Now admins
        can limit access to push and pull mirroring to only admin users, to
        prevent repositories being replicated to or from a GitLab instance.

    - name: Improved Geo nodes dashboard
      available_in: [premium, ultimate]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/ee/gitlab-geo/configuration.html#step-5-verify-proper-functioning-of-the-secondary-node'
      documentation_text: "Read through the documentation on Geo node management"
      image_url: '/images/10_3/geo-nodes.png'
      reporter: jramsay
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/3195'
      description: |
        Managing and monitoring of Geo nodes is improved by separating the
        monitoring interface from the process of adding and editing a Geo node.

    - name: Simplified PostgreSQL HA configuration
      available_in: [premium, ultimate]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/omnibus/roles/#postgres-roles'
      documentation_text: "Read through documentation on PostgreSQL roles"
      reporter: joshlambert
      issue_url: 'https://gitlab.com/gitlab-org/omnibus-gitlab/issues/2952'
      description: |
        In GitLab 10.2 [Postgres HA became generally available](https://about.gitlab.com/blog/2017/11/22/gitlab-10-2-released/#postgres-ha-is-now-generally-available), making it easy to set up a production Postgres database cluster using our Omnibus package.

        Now we are making it even easier with the introduction of [new Postgres roles](https://docs.gitlab.com/omnibus/roles/#postgres-roles). These roles significantly reduce the configuration required to set up standalone database nodes, by automatically turning off all other features and components.

    - name: GitLab Mattermost 4.4.5
      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: joshlambert
      description: |
        GitLab 10.3 includes [Mattermost 4.4.5](https://about.mattermost.com/blog/mattermost-4-4/), an [open source Slack alternative](https://about.mattermost.com/), whose newest release includes the beta release of plugin support, plus much more.

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

        * [Add Kubernetes executor connection with service account, bearer token can also be overwritten](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/744) – thank you [David Schile](https://gitlab.com/bajacondor) from Nordstorm's CI team for the contribution!
        * [Stop Docker Machine before removing it](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/718)
        * [Add `--checkout --force` options to `git submodule update --init`](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/704)
        * [Fix trailing `<nil>` in syslog logging](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/734)
        * [Fix Kubernetes executor job overwritten variables behavior](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/739)
        * [Add zip archive for windows release files](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/760)

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

#Omnibus and Performance improvements

    - 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: |
        * Additional warnings have been added for deprecated settings, and they now appear in red.
        * gpgme 2.1.15 is now packaged with Omnibus GitLab, making it easier to use [signed commits](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/index.html).
        * Git has been updated to 2.14.3
        * Docker Registry has been updated to 2.6.2
        * Redis has been updated to 3.2.11

    - name: Handling oudated replicas with database load balancing
      available_in: [premium, ultimate]
      gitlab_com: false
      documentation_link: https://docs.gitlab.com/ee/administration/database_load_balancing.html
      documentation_text: 'Read through the documentation on database load balancing'
      reporter: yorickpeterse
      description: |
        The database load balancer included in GitLab Enterprise Edition has
        been improved so it can handle replicas that are lagging behind too
        much. This has been combined with adjustments to the replica status
        checks to reduce the number of queries necessary to check if a replica
        is available.

        These changes allow the database load balancer to stop sending read-only
        queries to replicas when those replicas are lagging behind with
        replicating data from a primary.

        For more information check the merge request on
        [how we handled outdated replicas in the DB load balancer](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/3526).

    - 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.3
      documentation_text: See all the performance improvements in GitLab 10.3
      reporter: markpundsack
      description: |
        We are continuing to make great strides in improving
        the performance of GitLab in every release.
        [We're committed](/handbook/product/#performance) to not only
        making individual instances of GitLab even faster,
        but also to greatly improving the performance of GitLab.com,
        an instance that has over one million users!

        In GitLab 10.3 we are shipping 24 performance improvements for merge
        requests, CI/CD, Prometheus, frontend, and a lot more! Some of the
        noteworthy improvements include:

        * [Performance of loading large / many Wiki pages has been improved](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15276)
        * [Search performance has been improved by adjusting search behaviour based on the number of characters of the search query](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15592)
        * [The number of timestamp updates for issues and merge requests has been reduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15682)
        * [Redundant import status checks have been removed](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15752)
        * [Object allocation tracking has been removed to remove the negative impact this had on performance](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15834)
        * [Stop sending milestone and labels for Projects::MergeRequestsController#show.json requests](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15847)

# MVP
mvp:
  fullname: Vitaliy 'blackst0ne' Klachkov
  gitlab: blackst0ne
  description: |
    Vitaliy is no stranger to the MVP list, having been the MVP of the
    GitLab 10.1 release. For 10.3, he added [eight contributions](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&author_username=blackst0ne&milestone_title=10.3),
    including one of the most requested issues,
    being able to [customize the branch name when creating a new branch
    from an issue](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/13884)
    in the web UI. Another exciting one is [Mermaid support in the
    Markdown viewer](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15107).

    Thank you (again) Vitaliy for your contributions!

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

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

# UPGRADE BAROMETER
barometer:
  reporter: tiagonbotelho
  description: |
    To upgrade to GitLab 10.3 from the latest 10.2 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 background migrations.

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

    In this release we changed the directory structure layout that holds
    artifacts. Artifacts are still stored in the same directory, but if you
    sharded at a sub-directory level (which no one should be doing!), you should
    review your infrastructure before upgrading.

# 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 has been removed.

      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: Kubernetes integration service
    due: March 22nd, 2017.
    reporter: bikebilly
    description: |
      The [service integration for Kubernetes clusters](https://docs.gitlab.com/ee/user/project/integrations/kubernetes.html)
      has been deprecated and replaced by the new [Clusters configuration](https://docs.gitlab.com/ee/user/project/clusters/index.html).

      The integration is still accessible, but it will be partially limited in GitLab 10.4 and then eventually removed in GitLab 10.5.
      Existing configuration will be automatically migrated to the new **CI/CD > Clusters** page in GitLab 10.5.

  - feature_name: 'The <code>gitlab</code> Helm chart'
    due: March 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/charts/gitlab).

      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.
