update READMEs

content/README.md

@@ -61,8 +61,8 @@ Example that applies to GitHub.com and recent versions of GitHub Enterprise Serv
 ```yaml
 title: About your personal dashboard
 versions:
-  free-pro-team: '*'
+  fpt: '*'
-  enterprise-server: '>=2.20'
+  ghes: '>=2.20'
 ```
 
 Example that applies to all supported versions of GitHub Enterprise Server:
@@ -71,15 +71,15 @@ Example that applies to all supported versions of GitHub Enterprise Server:
 ```yaml
 title: Downloading your license
 versions:
-  enterprise-server: '*'
+  ghes: '*'
 ```
 
 You can also version a page for a range of releases. This would version the page for GitHub Enterprise Server 2.22 and 3.0 only:
 
 ```yaml
 versions:
-  free-pro-team: '*'
+  fpt: '*'
-  enterprise-server: '>=2.22 <3.1'
+  ghes: '>=2.22 <3.1'
 ```
 
 ### `redirect_from`
@@ -310,7 +310,7 @@ When using Liquid conditionals in lists or tables, you can use [whitespace contr
 Just add a hyphen on either the left, right, or both sides to indicate that there should be no newline on that side. For example, this statement removes a newline on the left side:
 
 ```
-{%- if currentVersion == 'free-pro-team@latest' %}
+{%- ifversion fpt %}
 ```
 
 ## Links and image paths

data/learning-tracks/README.md

@@ -25,7 +25,7 @@ Learning track data for a product is defined in two places:
 
     One learning track in this YAML **per version** must be designated as a "featured" learning track via `featured_track: true`, which will set it to appear at the top of the product sublanding page. A test will fail if this property is missing.
 
-    The `featured_track` property can be a simple boolean (i.e., `featured_track: true`) or it can be a string that includes versioning statements (e.g., `featured_track: '{% if currentVersion == "free-pro-team@latest" %}true{% else %}false{% endif %}'`). If you use versioning, you'll have multiple `featured_track`s per YML file, but make sure that only one will render in each currently supported version. A test will fail if there are more or less than one featured link for each version.
+    The `featured_track` property can be a simple boolean (i.e., `featured_track: true`) or it can be a string that includes versioning statements (e.g., `featured_track: '{% ifversion fpt %}true{% else %}false{% endif %}'`). If you use versioning, you'll have multiple `featured_track`s per YML file, but make sure that only one will render in each currently supported version. A test will fail if there are more or less than one featured link for each version.
 
 ## Versioning
 
@@ -40,7 +40,7 @@ learning_track_name:
   description: 'Learning track description'
   featured_track: true
   versions:
-    enterprise-server: '>=3.0'
+    ghes: '>=3.0'
   guides:
    - /path/to/guide1
    - /path/to/guide2

data/product-examples/README.md

@@ -29,7 +29,7 @@ At the moment, versioning is only supported in code examples. If an example bloc
     - Version updates
     - Pull requests
   versions:
-    'free-pro-team': '*'
+    fpt: '*'
   ```
 
 where the syntax for `versions` is the same as the [frontmatter `versions` property](content/README.md) and can support semver notation.