About upgrades to new releases

You can benefit from new features and bug fixes for GitHub Enterprise Server by upgrading your enterprise to a newly released version.

Note: Features such as GitHub Actions, GitHub Packages, GitHub for mobile and GitHub Advanced Security are available on GitHub Enterprise Server 3.0 or higher. We highly recommend upgrading to 3.0 or later releases to take advantage of critical security updates, bug fixes and feature enhancements.

GitHub Enterprise Server is constantly improving, with new functionality and bug fixes introduced through feature and patch releases.

Feature releases include new functionality and feature upgrades and typically occur quarterly.

Starting with GitHub Enterprise Server 3.0, all feature releases begin with at least one release candidate. Release candidates are proposed feature releases, with a complete feature set. There may be bugs or issues in a release candidate which can only be found through feedback from customers actually using GitHub Enterprise Server.

You can get early access to the latest features by testing a release candidate as soon as the release candidate is available. You can upgrade to a release candidate from a supported version and can upgrade from the release candidate to later versions when released. You should upgrade any environment running a release candidate as soon as the release is generally available. For more information, see "Upgrade requirements."

Release candidates should be deployed on test or staging environments. As you test a release candidate, please provide feedback by contacting support. For more information, see "Working with GitHub Support."

We'll use your feedback to apply bug fixes and any other necessary changes to create a stable production release. Each new release candidate adds bug fixes for issues found in prior versions. When the release is ready for widespread adoption, GitHub publishes a stable production release.

Warning: The upgrade to a new feature release will cause a few hours of downtime, during which none of your users will be able to use the enterprise. You can inform your users about downtime by publishing a global announcement banner, using your enterprise settings or the REST API. For more information, see "Customizing user messages on your instance" and "GitHub Enterprise administration."

Patch releases, which consist of hot patches and bug fixes only, happen more frequently. Patch releases are generally available when first released, with no release candidates. Upgrading to a patch release typically requires less than five minutes of downtime.

To upgrade your enterprise to a new release, see "Release notes" and "Upgrading GitHub Enterprise Server." Because you can only upgrade from a feature release that's at most two releases behind, use the Upgrade assistant to find the upgrade path from your current release version.

Further reading

Did this doc help you?

Privacy policy

Help us make these docs great!

All GitHub docs are open source. See something that's wrong or unclear? Submit a pull request.

Make a contribution

Or, learn how to contribute.