Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
G
gitlab-ce
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
1
Merge Requests
1
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
nexedi
gitlab-ce
Commits
39aad853
Commit
39aad853
authored
Nov 06, 2020
by
Marcel Amirault
Committed by
Evan Read
Nov 06, 2020
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Update details about version text
parent
89ae6833
Changes
2
Show whitespace changes
Inline
Side-by-side
Showing
2 changed files
with
54 additions
and
45 deletions
+54
-45
doc/.vale/gitlab/VersionText.yml
doc/.vale/gitlab/VersionText.yml
+1
-1
doc/development/documentation/styleguide.md
doc/development/documentation/styleguide.md
+53
-44
No files found.
doc/.vale/gitlab/VersionText.yml
View file @
39aad853
...
@@ -11,4 +11,4 @@ link: https://docs.gitlab.com/ee/development/documentation/styleguide.html#text-
...
@@ -11,4 +11,4 @@ link: https://docs.gitlab.com/ee/development/documentation/styleguide.html#text-
level
:
error
level
:
error
scope
:
raw
scope
:
raw
raw
:
raw
:
-
'
>
(-
){0}\[?Introduced.+\n
.+
'
-
'
>
(-
){0}\[?Introduced.+\n
[^\n`]
'
doc/development/documentation/styleguide.md
View file @
39aad853
...
@@ -337,8 +337,6 @@ In most cases, it’s appropriate to use the second-person (you, yours) point of
...
@@ -337,8 +337,6 @@ In most cases, it’s appropriate to use the second-person (you, yours) point of
view, because it’s friendly and easy to understand. (Tested in
view, because it’s friendly and easy to understand. (Tested in
[
`FirstPerson.yml`
](
https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/FirstPerson.yml
)
.)
[
`FirstPerson.yml`
](
https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/FirstPerson.yml
)
.)
<!-- How do we harmonize the second person in Pajamas with our first person plural in our doc guide? -->
### Capitalization
### Capitalization
#### Headings
#### Headings
...
@@ -556,8 +554,8 @@ tenses, words, and phrases:
...
@@ -556,8 +554,8 @@ tenses, words, and phrases:
appropriate way.
appropriate way.
-
Exceptions to this rule include commonly accepted technical terms, such as
-
Exceptions to this rule include commonly accepted technical terms, such as
CI/CD and TCP/IP.
CI/CD and TCP/IP.
-
<!-- vale gitlab.LatinTerms = NO -->
<!-- vale gitlab.LatinTerms = NO -->
We discourage the use of Latin abbreviations and terms, such as _e.g._,
-
We discourage the use of Latin abbreviations and terms, such as _e.g._,
_i.e._, _etc._, or _via_, as even native users of English can misunderstand
_i.e._, _etc._, or _via_, as even native users of English can misunderstand
those terms. (Tested in
[
`LatinTerms.yml`
](
https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/LatinTerms.yml
)
.)
those terms. (Tested in
[
`LatinTerms.yml`
](
https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/LatinTerms.yml
)
.)
-
Instead of _i.e._, use _that is_.
-
Instead of _i.e._, use _that is_.
...
@@ -565,7 +563,7 @@ tenses, words, and phrases:
...
@@ -565,7 +563,7 @@ tenses, words, and phrases:
-
Instead of _e.g._, use _for example_, _such as_, _for instance_, or _like_.
-
Instead of _e.g._, use _for example_, _such as_, _for instance_, or _like_.
-
Instead of _etc._, either use _and so on_ or consider editing it out, since
-
Instead of _etc._, either use _and so on_ or consider editing it out, since
it can be vague.
it can be vague.
<!-- vale gitlab.LatinTerms = YES -->
<!-- vale gitlab.LatinTerms = YES -->
-
Avoid using the word
*currently*
when talking about the product or its
-
Avoid using the word
*currently*
when talking about the product or its
features. The documentation describes the product as it is, and not as it
features. The documentation describes the product as it is, and not as it
will be at some indeterminate point in the future.
will be at some indeterminate point in the future.
...
@@ -1678,58 +1676,69 @@ item in the **Version history**, or as an inline reference with related text.
...
@@ -1678,58 +1676,69 @@ item in the **Version history**, or as an inline reference with related text.
#### Version text in the **Version History**
#### Version text in the **Version History**
If all content in a section is related, add version text
in a bulleted list
If all content in a section is related, add version text
following the header for
following the heading for the section
. To render correctly, it must be on its
the section. Each entry should be on a single line
. To render correctly, it must be on its
own line and surrounded by blank lines.
own line and surrounded by blank lines.
-
For features that need to declare the GitLab version that the feature was
Features should declare the GitLab version that introduced a feature in a blockquote
introduced. Text similar to the following should be added immediately following
following the header:
the heading as a blockquote:
-
`> Introduced in GitLab 11.3.`
.
-
Whenever possible, version text should have a link to the _completed_ issue,
```
markdown
merge request, or epic that introduced the feature. An issue is preferred over
## Feature name
a merge request, and a merge request is preferred over an epic. For example:
-
`> [Introduced](<link-to-issue>) in GitLab 11.3.`
.
-
If the feature is only available in GitLab Enterprise Edition, mention
> Introduced in GitLab 11.3.
the
[
paid tier
](
https://about.gitlab.com/handbook/marketing/strategic-marketing/tiers/
)
the feature is available in:
-
`> [Introduced](<link-to-issue>) in [GitLab Starter](https://about.gitlab.com/pricing/) 11.3.`
.
-
If listing information for multiple version as a feature evolves, add the
This feature does something.
information to a block-quoted bullet list. For example:
```
```
markdown
Whenever possible, version text should have a link to the _completed_ issue,
> - [Introduced](<link-to-issue>) in GitLab 11.3.
merge request, or epic that introduced the feature. An issue is preferred over
> - Enabled by default in GitLab 11.4.
a merge request, and a merge request is preferred over an epic. For example:
```
```
markdown
> [Introduced](<link-to-issue>) in GitLab 11.3.
```
-
If a feature is moved to another tier:
If the feature is only available in GitLab Enterprise Edition, mention
the
[
paid tier
](
https://about.gitlab.com/handbook/marketing/strategic-marketing/tiers/
)
the feature is available in:
```
markdown
```
markdown
> - [Introduced](<link-to-issue>) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.5.
> [Introduced](<link-to-issue>) in [GitLab Starter](https://about.gitlab.com/pricing/) 11.3.
> - [Moved](<link-to-issue>) to [GitLab Starter](https://about.gitlab.com/pricing/) in 11.8.
```
> - [Moved](<link-to-issue>) to GitLab Core in 12.0.
```
-
If a feature is deprecated, include a link to a replacement (when available):
If listing information for multiple version as a feature evolves, add the
information to a block-quoted bullet list. For example:
```
markdown
```
markdown
> - [Deprecated](<link-to-issue>) in GitLab 11.3. Replaced by [meaningful text](<link-to-appropriate-documentation>).
> - [Introduced](<link-to-issue>) in GitLab 11.3.
```
> - Enabled by default in GitLab 11.4.
```
It's also acceptable to describe the replacement in surrounding text, if
If a feature is moved to another tier:
available.
If the deprecation is not obvious in existing text, you may want to include a
```
markdown
warning such as:
> - [Introduced](<link-to-issue>) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.5.
> - [Moved](<link-to-issue>) to [GitLab Starter](https://about.gitlab.com/pricing/) in 11.8.
> - [Moved](<link-to-issue>) to GitLab Core in 12.0.
```
```
markdown
If a feature is deprecated, include a link to a replacement (when available):
DANGER:
**Deprecated:**
This feature was
[
deprecated
](
link-to-issue
)
in GitLab 12.3
```
markdown
and replaced by
[
Feature name
](
link-to-feature-documentation
)
.
> - [Deprecated](<link-to-issue>) in GitLab 11.3. Replaced by [meaningful text](<link-to-appropriate-documentation>).
```
```
You can also describe the replacement in surrounding text, if available.
If the deprecation is not obvious in existing text, you may want to include a
warning such as:
```
markdown
DANGER:
**Deprecated:**
This feature was
[
deprecated
](
link-to-issue
)
in GitLab 12.3
and replaced by
[
Feature name
](
link-to-feature-documentation
)
.
```
#### Inline version text
#### Inline version text
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment