Supported versions

Review the following information about supported release versions for Gloo Gateway, and supported versions of different open source projects within each Gloo Gateway release.

Gloo GatewayDateKubernetesKubernetes Gateway APIEnvoyHelmIstio
1.20.xTBD1.29 - 1.331.3.0v3 xDS API>= 3.121.21 - 1.25†
1.19.x13 May 20251.29 - 1.321.2.1v3 xDS API>= 3.121.21 - 1.25†
1.18.x12 Dec 20241.27 - 1.311.2.0v3 xDS API>= 3.121.18 - 1.23
1.17.x15 Jul 20241.25 - 1.291.0.0v3 xDS API>= 3.121.16 - 1.22

Gloo Gateway

Gloo Gateway Enterprise offers n-3 patching support for bug and critical security fixes. In other words, the current release and the three previous releases of Gloo Gateway are supported.

New features are not developed on or backported to stable branches. However, critical patches, bug fixes, and documentation fixes are backported to all actively supported branches.

Kubernetes

Gloo Gateway Enterprise is supported and tested with the latest Kubernetes version at the time of the Gloo Gateway release, and all Kubernetes versions that were released up to 1 year before the latest version.

Envoy

By default, Gloo Gateway Enterprise offers support for n-1 of Envoy community releases. In specific support situations, fixes can be backported to n-2 or more without bumping the Envoy minor version. In other words, a fix can be developed based on the code that you deployed within the n-2 release timeframe.

Istio

Istio must run on a compatible version of Kubernetes. For example, Istio 1.22 is tested, but not supported, on Kubernetes 1.26. For more information, see the Istio docs.

† In Gloo Gateway 1.19 and later, the following versions of Istio are supported:

Sidecar: n-4 version support, such as 1.21 - 1.25 in Gloo Gateway 1.19, is included for sidecar-based installations of Istio. For example, you can integrate Gloo Gateway as an ingress to a sidecar mesh.

Ambient: When using Istio in ambient mode, the version of Istio that is supported depends on the feature that you want to use in Gloo Gateway:

Image variants

For some Gloo Gateway component images, the following image variants are supported. Note that the fips and fips-distroless image variants are supported for Enterprise only.

  • Standard: The default image variant provided by Gloo Gateway. The standard variant does not require a tag on the image.
  • Distroless: An image tagged with -distroless is a slimmed-down distribution with the minimum set of binary dependencies to run the image, for enhanced performance and security. Distroless images do not contain package managers, shells, or any other programs that are generally found in a standard Linux distribution. The use of distroless variants is a standard practice adopted by various open source projects and proprietary applications.
  • FIPS (Enterprise only): An image tagged with -fips complies with National Institute of Standards and Technology (NIST) Federal Information Processing Standards (FIPS), for use cases that require federal information processing capabilities. For example, you might provide a cloud service that runs in a Federal Risk and Authorization Management Program (FedRAMP) regulated environment. In such cases, you can use Gloo Gateway’s FIPS images without the need for any additional tooling or CLIs.
  • FIPS and distroless (Enterprise only): An image tagged with -fips-distroless follows the same characteristics of both the distroless and FIPS image variants.
  • ARM (Enterprise only): An image that is tagged with -arm is compatible with ARM64 architectures. Note that ARM images are currently not supported for the Gloo AI gateway, and ARM binaries are not currently published for VMs.

Gloo Gateway supports image variants for the following component images:

  • access-logger
  • certgen
  • discovery
  • gloo
  • gloo-envoy-wrapper
  • ingress
  • kubectl
  • sds

You have two options for specifying the variant for a Gloo Gateway image in your Helm values:

  • Specify the image variant for all Gloo Gateway components in the global.image.variant Helm field. Supported values include standard, distroless, fips, and fips-distroless. If unset, the default value is standard.
  • Specify images for individual components by using variant tags in the gloo.<component>.deployment.image.tag field of the component’s Helm settings, such as quay.io/solo-io/gloo-ee:v1.20.0-beta1-distroless.

Release cadence

Gloo Gateway Enterprise releases are built on the OSS codebase and typically follow the equivalent Gloo Gateway OSS release. The OSS version is released as the latest build, while the Enterprise version is released as the first stable build of that version. For example, the latest build of Gloo Gateway OSS is 1.20.0-beta8, while the latest stable build of Gloo Gateway Enterprise is 1.20.0-beta1.

Stable builds for both Gloo Gateway Enterprise and OSS are released as minor versions approximately every three months. A stable branch for a minor version, such as 1.20, is tagged from main, and stable builds for both Enterprise and OSS are supported from that branch.

Release development

Alpha and beta release process

New features for Gloo Gateway Enterprise and OSS are developed on main.

  • For Enterprise, new features are often first released as beta builds. You can use these beta builds to test new features, or wait until the feature is released with the next stable Enterprise minor version.
  • For OSS, new features are released as patches off of main.

To receive feedback and improve functionality for real use cases, these features are often released according to a feature maturity model. As the features are improved and stabilized, they are gradually moved through the stages of alpha, beta, and general availability (GA) support. Review the following table for the comparison points between each stage of feature maturity. To see the maturity of a feature, check the feature’s documentation.

Comparison pointAlphaBetaGA
APICan and will likely changeUnlikely to changeNo change
ImplementationCan and will likely changeCan change, but user experience is maintainedNo changes that affect user experience
Upgrade pathsNot guaranteedNot guaranteedProvided and tested
Requests for enhancement (RFEs) and bug fixesRFEs and bug fixes prioritizedRFEs and bug fixes prioritizedFully supported
DocumentationNot guaranteed and supplied with warningsSupplied with warningsFully supplied
Automated testingInternal testing, but little testing with real use casesInternal testing and some testing with real use casesFully tested and validated with real use cases
Suggested usageExploration and feedbackTesting setups, demos, and POCsProduction setups

Stable release process

Development of a quality stable release on main typically follows this process:

  1. New feature development is suspended on main.
  2. Release candidates are created, such as 1.20.0-rc1, 1.20.0-rc2, and so on.
  3. A full suite of tests is performed for each release candidate. Testing includes all documented workflows, a test matrix of all supported platforms, and more.
  4. Documentation for that release is prepared, vetted, and staged.
  5. The stable minor version is released.
  6. Feature development on main is resumed.

Additional support

Have other questions? Reach out to us on Slack or email sales@solo.io.