New GHES releases are cut about every 3 months and around the same time, the oldest release is deprecated (unofficially supported). The release schedule is located here: src/ghes-releases/lib/enterprise-dates.json

• src/ghes-releases/lib - The release and deprecation issue templates used as a checklist.
• src/ghes-releases/scripts - The scripts used to create new releases and deprecations for GHES.
• src/ghes-releases/tests - The tests used to verify the GHES releases and deprecations

Slack: #docs-engineering Repo: github/docs-engineering

If you have a question about this feature, you can ask in the #docs-engineering Slack channel. If you notice a problem with this feature, you can open an issue in the github/docs-engineering repository.

Every day a workflow runs to check whether it's time to create new release tracking issues. New release tracking issues get opened on the code freeze date for the new release.

New release issues get opened in the docs-content repo and use the templates located in src/ghes-releases/lib/release-templates.

Templates can be added and removed by simply adding a new file to the release-template directory using the naming convention that already exists. For every template in that directory, a new issue will be created. The issues are linked together using the tasklist in the parent template release-steps-0.md. Each template file has a corresponding liquid variable for the issue url created from the template. The liquid variable format is {{ release-steps-<TEMPLATE NUMBER>-url }}. The liquid variables can be used in the templates to autopopulate issues and link issues together.

Templates in src/ghes-releases/lib/release-templates are Markdown, YAML frontmatter, and Liquid. The Liquid variables available to those templates are not the same as liquid variables used by the Docs team for content and data. See the Template variables for the available variables.

• {{ release-number }} - The GHES release number. For example, 3.13.
• {{ release-target-date }} - The target GHES release date. For example, 2021-09-01.
• {{ release-prp }} - The enterprise team's primary responsible person (PRP) for the release.
• {{release-feature-freeze-date }} - The feature freeze date for the release. For example, 2021-08-01.
• {{ release-code-freeze-date }} - The code freeze date for the release. For example, 2021-08-15.
• {{ release-rc-target-date }} - The release candidate target date for the release. For example, 2021-08-30.
• {{ release-steps-0-url }} - The URL of the issue that was created with the release-steps-0.md template.
• {{ release-steps-1-url }} - The URL of the issue that was created with the release-steps-1.md template.
• {{ release-steps-2-url }} - The URL of the issue that was created with the release-steps-2.md template.
• {{ release-steps-3-url }} - The URL of the issue that was created with the release-steps-3.md template.
• {{ release-steps-4-url }} - The URL of the issue that was created with the release-steps-4.md template.
• {{ release-steps-5-url }} - The URL of the issue that was created with the release-steps-5.md template.
• {{ release-rc-target-date-minus-1 }} - The day before the release candidate target date. For example, 2021-08-29.
• {{ release-rc-target-date-minus-2 }} - Two days before the release candidate target date. For example, 2021-08-28.
• {{ release-rc-target-date-minus-3 }} - Three days before the release candidate target date. For example, 2021-08-27.
• {{ release-rc-target-date-minus-4 }} - Four days before the release candidate target date. For example, 2021-08-26.
• {{ release-rc-target-date-minus-5 }} - Five days before the release candidate target date. For example, 2021-08-25.
• {{ release-rc-target-date-minus-6 }} - Six days before the release candidate target date. For example, 2021-08-24.
• {{ release-rc-target-date-minus-7 }} - Seven days before the release candidate target date. For example, 2021-08-23.

Every day a workflow runs to check whether it's time to create new deprecation tracking issues. New deprecation tracking issues get opened 7 days before the deprecation date. There is only one template used to generate the deprecation tracking issue (src/ghes-releases/lib/deprecation-steps.md).

The following scripts are available for manual execution:

For example, to create new release tracking issues, run:

npm run create-enterprise-issue

Run tests:

npm run test -- src/ghes-releases/tests

The scripts in src/ghes-releases/scripts/ support manual execution for:

• Creating release tracking issues
• Creating deprecation tracking issues
• Validating release dates
• Testing issue generation

The GHES release process is tightly coupled with versioning:

• Release numbers in src/versions/lib/enterprise-server-releases.ts
• New releases add to supported array
• Deprecated releases move to deprecated array
• Version detection logic uses these arrays

When a GHES version is deprecated:

1. Content is archived from docs-internal to docs-ghes-X.XX repos
2. Archive middleware proxies requests to archived content
3. See src/archives/ for archival process

Release and deprecation are coordinated:

• Release: Add new version to supported list
• Deprecation: Move old version to deprecated, trigger archival
• Both processes have tracking issues with checklists

• Workflows check daily for release/deprecation dates
• Issues created on code freeze date (releases) or 7 days before (deprecations)
• No manual trigger for early issue creation

• Liquid variables are custom (not same as content Liquid)
• Template changes require understanding of issue linking
• No preview mode for template rendering

• Multiple teams involved (Docs, Enterprise, Release Engineering)
• Manual checklist completion required
• Dependencies between issues must be manually tracked

• Dates in enterprise-dates.json must be manually updated
• No automated sync with Enterprise release calendar
• Changes require code update and deployment

We are not expecting significant new investment here, but we will continue to support GHES releases as needed.