features:
# TOP FEATURE
  top:
    - name: "Maven repository"
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/packages/maven_repository.html'
      image_url: '/images/11_3/maven.png'
      reporter: joshlambert
      team: package
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/5811'
      description: |
        For any development organization, having an easy and secure way to manage
        dependencies is critical. Package management tools, such as Maven for Java developers, provide
        a standardized way to share and version control these libraries across projects.

        In GitLab 11.3, we are proud to offer Maven repositories built directly into GitLab. Developers of
        lower-level services can now publish their packaged libraries to their project's Maven repository.
        They can then share a simple XML snippet with other teams looking to utilize that library,
        and Maven and GitLab will do the rest.

        Check out a [sample project](https://gitlab.com/gitlab-org/examples/mvn-example) which builds and
        pushes to the GitLab Maven repository, and see how easy it is!

# PRIMARY FEATURES
  primary:
    - name: "Interactive web terminals for Shell and Kubernetes Runners"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/ci/interactive_web_terminal/'
      image_url: '/images/11_3/verify-webterm.png'
      reporter: jyavorska
      team: verify
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/50144'
      description: |
        CI/CD jobs are executed by runners based on the configuration provided
        by users in their pipeline definition. But this execution is not
        interactive and, if it fails, users cannot dig into details to
        spot the possible source of the problem. Interactive web terminals
        bring the capability to connect to a running or completed job and
        manually run commands to better understand what's happening in the
        system.

    - name: "Improve includes in <code>.gitlab-ci.yml</code> for reusing scripts"
      available_in: [starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/ci/yaml/#extends'
      image_url: '/images/11_3/verify-includes.png'
      reporter: jyavorska
      team: verify
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/6136'
      description: |
        Reusing CI/CD process code is a great practice to help ensure
        consistency in software delivery, and minimizes the amount of per-job
        scripting that's needed to write and maintain. We now offer a flexible,
        powerful approach for code reuse in templates using YAML `extends`
        keywords.

    - name: "Include private contributions in user contribution graph"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/profile/#private-contributions'
      image_url: '/images/11_3/private-contributions-in-contribution-graph.png'
      reporter: akaemmerle
      team: manage
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/14078'
      description: |
        At GitLab, we love open source! But sometimes you want to work on a private project you don't
        want to share (yet), or you are constrained for confidentiality reasons. In any case, GitLab has
        got you covered.

        With this release, we are introducing the option to include private contributions in your
        profile's contribution graph. Contributions to private projects are now displayed in the
        contribution graph and contributions of this day if you enable this setting for your profile.
        This way, your active work on private GitLab projects is represented accurately, without
        giving away any private details.

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

    - name: "Redesigned project overview"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/'
      image_url: '/images/11_3/project-overview-redesign.png'
      reporter: akaemmerle
      team: manage
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/44704'
      description: |
        Iterating on our user interface is a constant focus for improving our product.

        With GitLab 11.3, we are updating the UI of the project overview page to allow for a better
        experience when exploring projects. Besides improving the overall information structure of
        this page, we are left-aligning the top header section and optimizing the vertical spacing, so
        you can get a quicker overview about the project and its content.

    - name: "Protected Environments"
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/ci/environments/protected_environments.html'
      image_url: '/images/11_3/protected-environments.png'
      reporter: danielgruesso
      team: configure
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/2747'
      description: |
        Operators are often responsible for the sensitive task of protecting the environments we
        deploy code to on a daily basis. This task becomes particularly important when deploying
        code to a production environment.

        With Protected Environments, operators obtain full control around which person, group, or account
        is allowed to deploy to a given environment, allowing further protection and safety of sensitive
        environments.

    - name: "Code Owners"
      available_in: [starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/code_owners.html'
      image_url: '/images/11_3/codeowners-file-widget.png'
      reporter: jramsay
      team: create
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/6961'
      description: |
        Code review is an essential practice of every successful project, but
        who should review the changes is not always clear. GitLab now supports
        assigning code owners to files to indicate the team members responsible
        for code in your project.

        Code owners are assigned using a file named `CODEOWNERS`, a format
        similar to [`gitattributes`](https://git-scm.com/docs/gitattributes),
        and are listed below the commit details when viewing a file in GitLab.

        In upcoming releases, Code Owners will be integrated into the merge
        request workflow to
        [suggest approvers](https://gitlab.com/gitlab-org/gitlab-ee/issues/5382),
        [assign approvers](https://gitlab.com/gitlab-org/gitlab-ee/issues/1012),
        and [enforce code owners](https://gitlab.com/gitlab-org/gitlab-ee/issues/4418).
        
    - name: "Epic forecasting with integrated milestone dates"
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/group/epics/'
      image_url: '/images/11_3/epic-integrated-milestone-dates.png'
      image_noshadow: true
      reporter: victorwu
      team: Plan
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/6470'
      description: |
        Prior to this release, you could set fixed values for the planned start
        date and the planned end date of an epic. This is useful for high-level
        planning of epics, and tracking them over time. However, as issues are
        attached to the epic, and the issues are scheduled for work with actual
        milestones, it would be useful to have the epic dates reflect those milestones.

        With this release, you can easily switch from the fixed value for either of
        the dates, to a dynamic value called `From milestones`. For the planned
        start date, this dynamic value will take on the earliest start date of all
        milestones assigned to the epic's attached issues. This is truly dynamic
        in that it will change if issues are added or removed, if milestones are
        assigned or unassigned (to those issues), or if the start dates are changed
        for those milestones. The dynamic version of the epic's planned end date
        is analogous.

        This feature is useful if you want to seamlessly transition from high-level,
        top-down planning to micro-level, bottom-up planning. See more in a
        [blog post on the Epics roadmap](/blog/2018/08/23/epics-roadmap/) that we published
        about this a few weeks back.

# SECONDARY FEATURES
  secondary:
    - name: "New epic event as custom notification"
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/profile/notifications.html'
      image_url: '/images/11_3/custom-notifications-new-epic.png'
      reporter: victorwu
      team: Plan
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/5863'
      description: |
        In a previous release, we provided email notifications for new epics,
        for users who have configured their group-level notifications to the
        `Watch` level. With this release, we are adding more customization.
        You can now configure this event trigger on or off using the `Custom` notification
        level, along with other event triggers.

    - name: "Quick action to add issue to epic (from issues)"
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/quick_actions.html'
      image_url: '/images/11_3/add-epic-quick-action.png'
      reporter: victorwu
      team: Plan
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/6959'
      description: |
        Adding an issue to an epic (or removing an already attached issue) is easily
        done from the epic page itself. This is useful for when you are already
        working in an epic.

        But sometimes you are working in an issue, and know that you want to attach
        it to an existing epic that you know about. You can now do so with a simple quick
        action on the issue page by pasting in the epic URL. In a future release,
        you'll even be able to [search for the epic in the quick action command via
        autocomplete](https://gitlab.com/gitlab-org/gitlab-ee/issues/7473).

        Additionally, another issue quick action will allow you to remove it from
        an already attached epic.

    - name: "Allow self-approval of merge requests"
      available_in: [starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_approvals.html#allowing-merge-request-authors-to-approve-their-own-merge-requests'
      reporter: jramsay
      team: create
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/3349'
      description: |
        The user who creates a merge request may not be the author of the
        changes, and other users may add additional changes to the merge
        request after it is opened. Maintainers can now allow self-approval
        of merge requests from the project settings.

        Previously, the user who opened the merge request was assumed to
        implicitly approve the merge request and was therefore excluded from
        approving the merge request. There are many situations where this is
        not true. Allowing self-approval removes this assumption.

    - name: "Display repository languages on project overview"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project'
      image_url: '/images/11_3/repository-languages.png'
      reporter: akaemmerle
      team: Manage
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/48647'
      description: |
        The code languages of which a repository consists is relevant information when exploring GitLab
        projects.

        With this release, we are adding a code languages bar to the project overview, showing all
        relevant languages the repository consists of, including their relative quantity.

    - name: "Custom file templates for self-managed instances"
      available_in: [premium, ultimate]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/ee/user/admin_area/settings/instance_template_repository.html'
      reporter: jramsay
      team: create
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/5306'
      description: |
        File templates for `LICENSE`, `.gitignore`, `Dockerfile` and
        `.gitlab-ci.yml` files make it easy to add these common files to
        projects. Custom file templates can now be added to self-managed GitLab
        instances by selecting an instance-wide template repository which
        contains your templates.

        Custom templates are useful when the templates provided by GitLab are
        too generic, for example a custom license that should be used for every
        project in the company, or a complex `Dockerfile` that should be used
        for every microservice.

        Thank you [Daniel Barker](https://gitlab.com/barkerd427) for
        contributing
        [custom license templates](https://gitlab.com/gitlab-org/gitlab-ee/issues/5986).

    - name: "File templates in the Web IDE"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/web_ide/'
      image_url: '/images/11_3/ide-templates.png'
      reporter: jramsay
      team: create
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/47947'
      description: |
        File templates for `LICENSE`, `.gitignore`, `Dockerfile` and
        `.gitlab-ci.yml` make it easy to add these common files to projects,
        and can now be used in the Web IDE. File templates in the Web IDE makes
        it easier to start a new project in the Web IDE and keep these
        important files up to date.

    - name: "Define project name when creating a new project"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/#new-project'
      image_url: '/images/11_3/project-name-on-new-project.png'
      reporter: akaemmerle
      team: manage
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/2934'
      description: |
        To add a project name to your newly created GitLab project, you previously had to go into the
        project settings and overwrite the project slug with a proper name.

        With GitLab 11.3, we are adding the project name field to the "Create project" form. In addition,
        the project slug is now automatically generated from the project name, while still allowing
        you to adjust this field. This improvement makes the process of creating a new project faster
        and more straightforward.

    - name: "Store Wiki uploads in the Wiki repository"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/wiki/'
      reporter: jramsay
      team: create
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/33475'
      description: |
        Images uploaded to the wiki through the wiki editor are now stored in
        the Git repository. This means images will now be display when
        previewing a wiki locally using [Gollum](https://github.com/gollum/gollum).

        Previously, images were stored in the project uploads directory with
        attachments uploaded to issues and merge requests. This prevented wikis
        from being previewed locally or being migrated to a different Git
        repository.

    - name: "SAST support for Groovy"
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/application_security/sast/'
      reporter: bikebilly
      team: secure
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/5251'
      description: |
        Static Application Security Testing is responsible for spotting vulnerabilities in your
        source code as soon as it is committed to the repository, looking for known patterns
        and common errors that may lead to security flaws in the final application.
        That's why each different language needs specific support.

        With GitLab 11.3, we introduce [Groovy](https://en.wikipedia.org/wiki/Apache_Groovy)
        in the list of languages supported by GitLab SAST. Projects using this language are
        now automatically detected and you don't need to change anything to your code or your
        pipeline definition to enable this feature. Auto DevOps is also supporting it as part
        of its default configuration.

    - name: "Filter webhook push events by branch"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/integrations/webhooks.html'
      image_url: '/images/11_3/filter-hooks.png'
      reporter: jramsay
      team: create
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/20338'
      description: |
        Webhooks for push events make it easy to automatically notify external
        services of new commits, but all branches are rarely of equal
        importance. Push events can now be filtered by branch so that
        external services are only notified about the changes that matter to
        you.

        Previously webhooks could not be filtered by GitLab, and most external
        systems do not have a feature filter incoming events. This meant it was
        not possible to integrate these services directly with GitLab if you
        only wanted a subset of push events to be used by the external service.

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

    - name: "Alerts for library metrics"
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#setting-up-alerts-for-prometheus-metrics'
      image_url: '/images/11_3/alerts_metrics_library.png'
      reporter: joshlambert
      team: monitor
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/6948'
      description: |
        In GitLab 11.2, we added the ability to set alerts for [custom metrics](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#adding-additional-metrics), which allowed developers to be notified
        in the event of any issues with their applications.

        With GitLab 11.3, we have now extended support for alerts to all metrics, including the metrics that
        are provided by default with our [library metrics](https://docs.gitlab.com/ee/user/project/integrations/prometheus_library/metrics.html).

    - name: "Auto DevOps enabled by default"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/topics/autodevops/'
      image_url: '/images/11_3/auto-devops-enabled-by-default.png'
      reporter: danielgruesso
      team: configure
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/50193'
      description: |
        Auto DevOps was made generally available in GitLab’s 11.0 release and while it has
        had great adoption, we want all GitLab users to take advantage of its great features.
        From Auto Build to Auto Monitoring, Auto DevOps brings valuable benefits out of the box.

        Starting with GitLab 11.3, Auto DevOps will be enabled by default on both GitLab.com and on
        self-managed instances, so that every project can take advantage of its features.

        Read through the documentation on [enabling/disabling Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/#enabling-auto-devops) if you wish to disable it for your project or for an entire instance.

    - name: "Geo improvements"
      available_in: [premium, ultimate]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/ee/administration/geo/replication/configuration.html'
      reporter: akaemmerle
      issueboard_url: 'https://gitlab.com/groups/gitlab-org/-/boards/763904?milestone_title=11.3&&label_name[]=Geo'
      description: |
        We continually focus on improving our [Geo](/solutions/geo/) feature for distributed teams. Some of the noteworthy improvements in GitLab 11.3 include:

        - [`git fetch` and `git push` operations on secondary Geo nodes are now automatically redirected to the primary node when using SSH](https://gitlab.com/gitlab-org/gitlab-ee/issues/6533)
        - [Disabled project wikis are now synced correctly](https://gitlab.com/gitlab-org/gitlab-ee/issues/6142)
        - [Checksum progress on Geo Admin Area page is now reflecting correct percentage states](https://gitlab.com/gitlab-org/gitlab-ee/issues/6028)
        - [Update events from fork merge requests are now generated correctly](https://gitlab.com/gitlab-org/gitlab-ee/issues/7245)

        You can also read about [how we built GitLab Geo](/blog/2018/09/14/how-we-built-gitlab-geo/).

    - name: "Automatically disable Auto DevOps for project upon first pipeline failure"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/topics/autodevops/#enabling-auto-devops'
      image_url: '/images/11_3/disable-autodevops-on-failure.png'
      reporter: danielgruesso
      team: configure
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/39923'
      description: |
        At GitLab, one of our product values is to [default to on](/handbook/product/#principles).
        When we introduce a new configurable feature we know to be of great value, we will
        default to ON so that everyone can benefit from it. While Auto DevOps supports
        projects using the most popular programming languages, there may be some specialized
        projects for which additional configuration is required.

        Because we want to ensure we will not be running Auto DevOps pipelines for projects
        that are not supported, we will disable Auto DevOps automatically if one of its pipelines fails.
        GitLab will notify the project owner of this attempt so they can make the necessary
        configuration changes to work with Auto DevOps if desired. Once the necessary changes are made,
        project owners can re-enable Auto DevOps.

    - name: "Gitaly v1.0"
      available_in: [core, starter, premium, ultimate]
      documentation_link: '/blog/2018/09/12/the-road-to-gitaly-1-0/'
      reporter: jramsay
      team: gitaly
      issue_url: 'https://gitlab.com/groups/gitlab-org/-/epics/287'
      description: |
        Git access for regular usage of GitLab can now occur entirely through
        Gitaly, GitLab's gRPC service to access Git. This means it is possible
        to run Gitaly on its own server without NFS when all optional feature
        flags are enabled.

        In the upcoming [Gitaly v1.1](https://gitlab.com/groups/gitlab-org/-/epics/288)
        release all feature flags will be enabled by default, and the last
        few remaining features will use Gitaly, removing the need for NFS.

        Read our blog post about
        [the road to Gitaly v1.0](/blog/2018/09/12/the-road-to-gitaly-1-0/).

    - name: List of open source software components used by GitLab now available online
      available_in: [core, starter, premium, ultimate]
      reporter: joshlambert
      team: distribution
      description: |
        Starting with GitLab 11.3, we are making the list of open source software used by
        GitLab more easily available. Prior to this release, it was available in each of our
        Linux packages, but that required downloading and extracting the contents.

        We are now publishing this content online, so it is easier to access and link to.
        The list is available for [GitLab CE](https://gitlab-org.gitlab.io/omnibus-gitlab/gitlab-ce.html) and [GitLab EE](https://gitlab-org.gitlab.io/omnibus-gitlab/gitlab-ee.html).

    - name: GitLab Runner 11.3
      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 11.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 initial support for CI Web Terminal](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/934)
        - [Introduce GCS adapter for remote cache](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/968)
        - [Update Docker images to `alpine:3.8`](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/984)
        - [Make configuration of helper image more dynamic](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1005)
        - [Fix incorrectly generated `Content-Range` header for `PATCH /api/v4/jobs/:id/trace` request](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/906)
        - [Fix HTTPS validation problem when ssh executor is used](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/962)

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

# Omnibus and performance

    - name: "Performance improvements"
      available_in: [core, starter, premium, ultimate]
      performance_url: https://gitlab.com/groups/gitlab-org/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&label_name%5B%5D=performance&milestone_title=11.3
      reporter: multiple
      team: multiple
      description: |
        Some of the more noteworthy performance improvements in GitLab 11.3 include:

        - [Speed up first load of a newly created merge request by highlighting and caching diffs in the background upon creation](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21489)
        - [Speed up loading of 'Last commit' column in tree views by performing Markdown rendering of commit titles in bulk](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21500)

    - name: "Omnibus improvements"
      available_in: [core, starter, premium, ultimate]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/omnibus/'
      reporter: joshlambert
      team: distribution
      description: |
        - GitLab 11.3 includes [Mattermost 5.2](https://mattermost.com/blog/mattermost-5-2-upgraded-plugin-system-search-archived-channels-romanian-language-support-and-more/),
        an [open source Slack-alternative](https://mattermost.com/) which includes an
        upgraded plugin system, ability to search archived channels, Romanian language
        support, and much more. Since it includes
        [security updates](https://about.mattermost.com/security-updates/), upgrading is recommended.
        - `gitlab-elasticsearch-indexer` has been updated to 0.2.2.
        - `omnibus-ctl` has been updated to 0.6.0.
        - The Redis [tcp_backlog](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template) and
        [HZ](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template#L823)
        settings are now configurable, as well as
        [max_concurrency](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template#L1600)
        in sidekiq_cluster.
        - The default maximum memory Sidekiq can use is now 2GB.
        - SSL compression has been disabled by default for `gitlab-psql` and `gitlab-geo-psql`.

# MVP
mvp:
  fullname: "George Tsiolis"
  gitlab: gtsiolis
  description: |
    George added a very popular and highly requested feature that allows users to 
    [include private contributions](#include-private-contributions-in-user-contribution-graph)
    on their own profile page.

    Thank you, George, for your ongoing contributions to make GitLab even better!
    You’ll receive a brand new swag pack soon!

# COVER IMAGE LICENCE
cover_img:
  image_url: 'https://unsplash.com/photos/Sl-2gao5QE4'
  licence: Unsplash
  licence_url: 'https://unsplash.com/license'

# CTA BUTTONS
cta:
  - title: "Join us for an upcoming event"
    link: '/events/'
  - title: "Watch the 11.3 Release Radar webcast"
    link: 'https://youtu.be/3CVpejJQpyE'

# UPGRADE BAROMETER
barometer:
  reporter: reprazent
  description: |
    To upgrade to GitLab 11.3 from the latest 11.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,
    to help with the larger migrations, we have introduced background migrations.

    GitLab.com migrations took approximately nine minutes and post-deploy
    migrations amounted for a total of around 15 minutes. Background
    migrations on the other hand are Sidekiq jobs that will run synchronously,
    for this release we expect the migrations to take rougly 90 days to
    complete on GitLab.com. The migration modifies all build-artifact
    information to a new format.

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

# DEPRECATIONS
deprecations:
  - feature_name: "Support for Docker Versions in GitLab Runner"
    due: October 22, 2018
    reporter: jyavorska
    description: |
      With GitLab 11.4 (October 22, 2018), support for Docker versions before 1.12 (API version 1.24) will be deprecated in line with
      Docker's latest [version recommendation guidance](https://docs.docker.com/develop/sdk/#api-version-matrix). Beyond
      the 11.4 release these older versions will no longer be officially supported and could stop working at any time.
