8a1870700a
* Describe new "only notify requested members" changes * Rename file * Update links * Update gated feature callout * Restructure a bit * Use feature flag * Rearrange conditional * Fix procedural versioning * Restructure again * Remove screenshot * Fix versioning * Split out version for recent other enhancements * This will be shipped in GHES 3.4 not 3.5 * Close liquid tag * Remove incorrect table row Co-authored-by: Laura Coursen <lecoursen@github.com> Co-authored-by: Melanie Yarbrough <11952755+myarb@users.noreply.github.com> Co-authored-by: Ethan Palm <56270045+ethanpalm@users.noreply.github.com>
Feature-based versioning
Feature-based versioning allows us to define and control the versions of an arbitrarily named "feature" in one place.
Note: Do not delete data/features/placeholder.yml because it is used by tests.
How it works
Add a new YAML file with the feature name you want to use in this directory. For a feature named meow, that would be data/features/meow.yml.
Add a versions block to the YML file with the short names of the versions the feature is available in. For example:
versions:
fpt: '*'
ghes: '>3.1'
ghae: '*'
The format and allowed values are the same as the frontmatter versions property.
Liquid conditionals
Now you can use {% if meow %} ... {% endif %} in content files! Note this is the if tag, not the new ifversion tag.
Frontmatter
You can also use the feature in frontmatter in content files:
versions:
fpt: '*'
ghes: '>3.1'
feature: 'meow'
If you want a content file to apply to more than one feature, you can do this:
versions:
fpt: '*'
ghes: '>3.1'
feature: ['meow', 'blorp']
Schema enforcement
The schema for validating the feature versioning lives in tests/helpers/schemas/feature-versions.js and is exercised by tests/content/lint-files.js.
Script to remove feature tags
TBD!