Skip to content
GitLab

Documenting product versions

The GitLab product documentation includes version-specific information, including when features were introduced and when they were updated or removed.

View older documentation versions

Previous versions of the documentation are available on docs.gitlab.com. To view a previous version, select the Versions button in the top right.

To view versions that are not available on docs.gitlab.com:

  • View the documentation archives.
  • Go to the GitLab repository and select the version-specific branch. For example, the 13.2 branch has the documentation for GitLab 13.2.

Documenting version-specific features

When a feature is added or updated, you can include its version information either as a Version history list item or as an inline text reference.

You do not need to add version information on the pages in the /development directory.

Add a Version history item

If all content in a topic is related, add a version history item after the topic heading. For example:

## Feature name

> [Introduced](<link-to-issue>) in GitLab 11.3.

This feature does something.

The item text must include these words in order. Capitalization doesn't matter.

  • introduced, enabled, deprecated, changed, moved, recommended, removed, or renamed
  • in or to
  • GitLab

If possible, include a link to the related issue, merge request, or epic. Do not link to the pricing page. Do not include the subscription tier.

Introducing a new feature

If you use introduced, start the sentence with the feature name or a gerund:

> - Notifications for expiring tokens [introduced](<link-to-issue>) in GitLab 11.3.
> - Creating an issue from an issue board [introduced](<link-to-issue>) in GitLab 13.1.

Moving subscription tiers

If a feature is moved to another subscription tier, use moved:

> - [Moved](<link-to-issue>) from GitLab Ultimate to GitLab Premium in 11.8.
> - [Moved](<link-to-issue>) from GitLab Premium to GitLab Free in 12.0.

Inline version text

If you're adding content to an existing topic, you can add version information inline with the existing text. If possible, include a link to the related issue, merge request, or epic. For example:

The voting strategy [in GitLab 13.4 and later](<link-to-issue>) requires the primary and secondary
voters to agree.

Deprecations and removals

When features are deprecated and removed, update the related documentation.

API documentation follows these guidelines, but the GraphQL docs use a separate process.

Deprecate a page or topic

To deprecate a page or topic:

  1. Add (deprecated) after the title. Use a warning to explain when it was deprecated, when it will be removed, and the replacement feature.

    ## Title (deprecated) **(ULTIMATE SELF)**

WARNING:
This feature was [deprecated](<link-to-issue>) in GitLab 14.8
and is planned for removal in 15.4. Use [feature X](<link-to-issue>) instead.

    If you're not sure when the feature will be removed or no replacement feature exists, you don't need to add this information.

  2. If the deprecation is a breaking change, add this text:

    This change is a breaking change.

    You can add any additional context-specific details that might help users.

  3. Open a merge request to add the word (deprecated) to the left nav, after the page title.

Remove a page

Mark content as removed during the release the feature was removed. The title and a removed indicator remains until three months after the removal.

To remove a page:

  1. Leave the page title. Remove all other content, including the version history items and the word WARNING:.

  2. After the title, change (deprecated) to (removed).

  3. Update the YAML metadata:

    • For remove_date, set the value to a date three months after the release when the feature was removed.
    • For the redirect_to, set a path to a file that makes sense. If no obvious page exists, use the docs home page.
    ---
stage: Data Stores
group: Global Search
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
remove_date: '2022-08-02'
redirect_to: '../newpath/to/file/index.md'
---

# Title (removed) **(ULTIMATE SELF)**

This feature was [deprecated](<link-to-issue>) in GitLab X.Y
and [removed](<link-to-issue>) in X.Y.
Use [feature X](<link-to-issue>) instead.

  4. Remove the page's entry from the global navigation by editing navigation.yaml in gitlab-docs.

This content is removed from the documentation as part of the Technical Writing team's regularly scheduled tasks.

Remove a topic

To remove a topic:

  1. Leave the title and the details of the deprecation and removal. Remove all other content, including the version history items and the word WARNING:.

  2. Add (removed) after the title.

  3. Add the following HTML comments above and below the topic. For the remove_date, set a date three months after the release where it was removed.

    <!--- start_remove The following content will be removed on remove_date: 'YYYY-MM-DD' -->

## Title (removed) **(ULTIMATE SELF)**

This feature was [deprecated](<link-to-issue>) in GitLab X.Y
and [removed](<link-to-issue>) in X.Y.
Use [feature X](<link-to-issue>) instead.

<!--- end_remove -->

This content is removed from the documentation as part of the Technical Writing team's regularly scheduled tasks.

Which versions are removed

GitLab supports the current major version and two previous major versions. For example, if 15.0 is the current major version, all major and minor releases of GitLab 15.0, 14.0, and 13.0 are supported.

View the list of supported versions.

If you see version history items or inline text that refers to unsupported versions, you can remove it.

Historical feature information is available in release posts or by searching for the issue or merge request where the work was done.

Promising features in future versions

Do not promise to deliver features in a future release. For example, avoid phrases like, "Support for this feature is planned."

We cannot guarantee future feature work, and promises like these can raise legal issues. Instead, say that an issue exists. For example:

  • Support for improvements is tracked [in this issue](LINK).
  • You cannot do this thing, but [an issue exists](LINK) to change this behavior.

You can say that we plan to remove a feature.

Legal disclaimer for future features

If you must write about features we have not yet delivered, put this exact disclaimer near the content it applies to.

DISCLAIMER:
This page contains information related to upcoming products, features, and functionality.
It is important to note that the information presented is for informational purposes only.
Please do not rely on this information for purchasing or planning purposes.
As with all projects, the items mentioned on this page are subject to change or delay.
The development, release, and timing of any products, features, or functionality remain at the
sole discretion of GitLab Inc.

It renders on the GitLab documentation site as:

DISCLAIMER: This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

If all of the content on the page is not available, use the disclaimer once at the top of the page.

If the content in a topic is not ready, use the disclaimer in the topic.