jprdonnelly/docs
1
0
Fork 0
mirror of synced 2025-12-22 19:34:15 -05:00
Code Issues Projects Releases Wiki Activity

Fix broken links 2023-08-03 (#40249)

Browse Source 
Co-authored-by: Siara <108543037+SiaraMist@users.noreply.github.com>
This commit is contained in:
Joe Clark
2023-08-09 01:32:11 -07:00
committed by GitHub
parent e243711ca1
commit 8b18b80701
3 changed files with 12 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
content/contributing/syntax-and-versioning-for-github-docs/versioning-documentation.md
View File

@@ -24,15 +24,15 @@ There are two types of versioning syntax for {% data variables.product.prodname_
PRODUCT: 'VERSIONS'
...
```
The following example shows content versioned for {% data variables.product.prodname_dotcom_the_website %}, and all versions of {% data variables.product.prodname_ghe_server %}.
```yaml
versions:
fpt: *
ghes: *
```
- Liquid: Used within Markdown files in `content/` and `data/reusables/`, variable strings within YAML files in `data/variables/`, or strings within `data/glossaries/external.yml`. Indicates which text should appear when a reader chooses a version for content that has multiple versions defined by YAML front matter.
- Product-based versioning:
@@ -40,7 +40,7 @@ There are two types of versioning syntax for {% data variables.product.prodname_
```javascript
{% raw %}{% ifversion SHORT-PRODUCT-NAME %} ... {% endif %}{% endraw %}
```
- Feature-based versioning:
```javascript
@@ -208,7 +208,7 @@ You cannot use `feature:` to specify multiple concurrent versions, as this is no
### Schema enforcement
The schema for validating the feature versioning lives in [`src/content-linter/lib/feature-versions-schema.js`](https://github.com/github/docs/blob/main/src/content-linter/lib/feature-versions-schema.js) and is exercised by [`tests/linting/lint-versioning.js`](https://github.com/github/docs/blob/main/tests/linting/lint-versioning.js).
The schema for validating the feature versioning lives in [`src/content-linter/lib/feature-versions-schema.js`](https://github.com/github/docs/blob/main/src/content-linter/lib/feature-versions-schema.js) and is exercised by [`tests/linting/lint-versioning.js`](https://github.com/github/docs/blob/main/src/content-linter/tests/lint-versioning.js).
## Versioning for {% data variables.product.prodname_ghe_managed %}
@@ -227,7 +227,7 @@ You can version documentation to appear in the current {% data variables.product
### About the displayed version of {% data variables.product.prodname_ghe_managed %} documentation
We display one version of {% data variables.product.prodname_ghe_managed %} documentation on {% data variables.product.prodname_docs %}: the latest. We define "latest" in the site's source, within [`all-versions.js`](https://github.com/github/docs/blob/main/lib/all-versions.js#L58). In almost all cases, this value is a safe place to determine the latest public release of {% data variables.product.prodname_ghe_managed %}.
We display one version of {% data variables.product.prodname_ghe_managed %} documentation on {% data variables.product.prodname_docs %}: the latest. We define "latest" in the site's source, within [`all-versions.js`](https://github.com/github/docs/blob/main/lib/all-versions.js#L58). In almost all cases, this value is a safe place to determine the latest public release of {% data variables.product.prodname_ghe_managed %}.
"Latest" corresponds with the latest version of {% data variables.product.prodname_ghe_managed %} that we've deployed to the first customer using the product in production. Generally, {% data variables.product.company_short %} upgrades all production customers on {% data variables.product.prodname_ghe_managed %} to the latest version around the same time, so Product considers only showing the latest documentation an acceptable compromise.
@@ -248,7 +248,7 @@ For the reader, gaining a general understanding is more important than reading d
### When modifying an existing content file, review existing versioning early and often
Staying cognizant of existing versioning will help ensure that you write relevant versioning statements, and can help remind you to version new content accurately.
- Do review the entire page's versioning in the front matter as soon as you begin editing.
- Do review the versioning around content that you're editing.
- Do review the rendered version of changes that you're making, and switch to each available version for the page as part of your self-review.
@@ -257,10 +257,10 @@ Staying cognizant of existing versioning will help ensure that you write relevan
Use versioning syntax within a sentence or paragraph to differentiate prose for two different plans or products. A contributor can edit just one paragraph with versioning statements, instead of needing to consider larger blocks of versioned text and modify similar but differently versioned prose in two places. A reviewer can suggest a change once, instead of needing to leave the same suggestion in multiple places. But if the behavior differs dramatically or versioning within the sentence or paragraph becomes complicated or difficult for a contributor to parse, consider repeating yourself to make the prose easier to maintain.
- Do use versioning syntax inline within paragraphs to avoid repeating sentences or entire paragraphs.
- Do use versioning syntax inline within paragraphs to avoid repeating sentences or entire paragraphs.
> You can do {% raw %}{% ifversion fpt %}something{% elsif ghec %}something else{% endif %}{% endraw %}.
- Do use your judgment: for prose that would be complicated to write or read without lots of versioning syntax within a sentence or paragraph, consider repeating the entire paragraph in a version block for each relevant product.
> {% raw %}{% ifversion fpt %}