- View older documentation versions
- Documenting version-specific features
- Deprecations and removals
- Which versions are removed
- Promising features in future versions
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 upper 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 title. 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
, orrenamed
-
in
orto
-
GitLab
(or, for external projects, the name of the project)
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.
Features introduced behind feature flags
When features are introduced behind feature flags, you must add details about the feature flag to the documentation. For more information, see Document features deployed behind feature flags.
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:
-
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.
-
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.
-
Add the following HTML comments above and below the content. For the
remove_date
, set a date three months after the release where it was deprecated.<!--- start_remove The following content will be removed on remove_date: 'YYYY-MM-DD' --> ## 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. <!--- end_remove -->
-
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:
- Leave the page title. Remove all other content, including the version history items and the word
WARNING:
. - After the title, change
(deprecated)
to(removed)
. - 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/product/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.
- For
- Remove the page’s entry from the global navigation by editing
navigation.yaml
ingitlab-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:
- Leave the title and the details of the deprecation and removal. Remove all other content,
including the version history items and the word
WARNING:
. - Add
(removed)
after the title. -
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 proposed in
[issue <issue_number>](LINK-TO-ISSUE)
. - You cannot do this thing, but
[issue 12345](LINK-TO-ISSUE)
proposes 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 about forward-looking statements 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:
If all of the content on the page is not available, use the disclaimer about forward-looking statements once at the top of the page.
If the content in a topic is not ready, use the disclaimer in the topic.