Red Hat build of Quarkus Life Cycle and Support Policies

Overview

The Red Hat build of Quarkus is an implementation of the Quarkus community project.

The Red Hat build of Quarkus productizes a subset of the extensions provided in Quarkus and the Quarkiverse community. The Red Hat build of Quarkus Component Details page provides more details on exactly which extensions are productized and their support status. The Red Hat build of Quarkus is also tested and verified on various platforms and JVMs, as described on the Red Hat build of Quarkus Supported Configurations page.

Major versions

Starting from the Red Hat build of Quarkus 3.x, a major version indicates a support life cycle (full and maintenance) of a minimum of 3 years. We usually end full support when a new Major version is ready. If the next major version is not ready when full support ends, the current version will remain in full support until a new major version is available. When a new major version is released, the previous major version goes into maintenance for at least six months so customers can upgrade. Major releases do not provide any guarantees of backward compatibility, supported configuration, or support for the same components as the previous major version.

Minor versions

Minor versions are where we introduce new features and changes that are considered not to be backward-breaking. The Red Hat team working with Quarkus takes good care of making sure that changes between minor versions do not break customers' applications. However, Quarkus is based on many different APIs (Jakarta, Microprofile, etc.) and other popular communities, so absolute backward compatibility cannot be guaranteed. Another example where keeping backward compatibility may not be possible is in security fixes. In most cases, changes to behavior, etc, are introduced via feature flags so that applications can retain the old behavior.

Minor versions in the Red Hat build of Quarkus work a bit special. They are based on the community LTS releases and are not precisely one-version increments. For example, after the Red Hat build of Quarkus 3.2, the next expected minor version is 3.8, and the following version might be 3.14. The latest minor version is fully supported, and the previous version is considered in maintenance for six months, starting when a new minor version is released.

Deprecation of components and supported configurations

We aim to keep components and supported platforms consistent throughout the major life cycle. Still, there are situations where we have to deprecate and remove a component or support for a platform within a major life cycle. Examples of these are:

• When a supported platform (Java version, OS version, etc) goes out of full support, we also stop testing and verifying that platform.
• Removal of features in standards: For example, the Java Community, MicroProfile, and Jakarta EE governance may decide to remove standards/features that are considered legacy. We are normally careful about adopting new breaking versions of standards. Still, to adopt new standards, we reserve the right to remove components that are also removed from standardization.
• Deprecation of legacy components. In the developer community, the popularity of different components may vary over time. If an upstream project loses funding or becomes unpopular, we reserve the right to deprecate that component to indicate that it might be removed in the next minor release. For example, in earlier Quarkus versions, we supported Microprofile Metrics and Micrometer, which are complementary technologies. Since then, the industry has been moving towards OpenTelemetry Metrics. Because Micrometer is more closely related to how OpenTelmetry Metrics works, we have decided to deprecate MicroProfile Metrics in the Red Hat build of Quarkus 3.2. We might remove support for MicroProfile Metrics in a future version. To understand more about this motivation, see Quarkus Observability Roadmap 2023.

If removing a component or a support configuration is required within a minor life cycle, Red Hat commits to giving reasonable notice (deprecation) before removing a component or supported configuration with at least one full minor release. This means that customers have approximately one year (until the next minor release plus six months) to use another component or upgrade the system where the Red Hat build of Quarkus is running.

Life Cycle

The life cycle for a major release of Red Hat build of Quarkus is divided into two primary phases: the Full Support Phase, the Maintenance Phase.

Red Hat build of Quarkus conforms to the following life cycle phases:

Phase 1: Full Support

Full support is provided according to the published Scope of Coverage and Service Level Agreement. Likewise, Development Support is provided according to the published Scope of Coverage and Service Level Agreement. All available and qualified patches will be applied via periodic product updates and patches, or as required for qualified security patches.

Full Support starts with a new Red Hat build of Quarkus major release and ends when a new Red Hat build of Quarkus major version is released.

Phase 2: Maintenance Support

Production support is provided according to the published Scope of Coverage and Service Level Agreement. Likewise, Development Support is provided according to the published Scope of Coverage and Service Level Agreement. During the maintenance phase, qualified security patches of Critical or Important impact and select mission-critical bug-fix patches will be released.

Maintenance Support for the prior existing major version begins when a new Red Hat build of Quarkus major version is released. It usually lasts for six months.

The following table details each type of software maintenance performed during a typical life cycle:

Product Life Cycle Dates

Listed below are the life cycle dates for the currently supported Red Hat build of Quarkus Releases.