Open source

Delivering the latest and greatest

A look into PatternFly’s release process

The new era of PatternFly 5 is on the horizon, which makes this the perfect time to peel back the curtain and share a little more about how PatternFly’s codebase is updated and released. If you’ve ever taken a look at all of PatternFly’s GitHub issues, you’ll know that the team is always working hard on improving and enhancing PatternFly.

To provide insight into how PatternFly evolves and how the PatternFly team works, this article lays out the higher-level steps and shares details about our (recently enhanced) release process.

PatternFly releases include updates to its packages and extensions, which include the following:

Packages:

• @patternfly/patternfly
• @patternfly/react-core
• @patternfly/react-charts
• @patternfly/react-table
• @patternfly/react-tokens
• @patternfly/react-icons
• @patternfly/react-code-editor

Extensions:

• @patternfly/react-catalog-view-extensions
• @patternfly/react-topology
• @patternfly/react-console
• @patternfly/quickstarts
• @patternfly/user-feedback
• @patternfly/react-log-viewer
• @patternfly/react-component-groups

The release cadence for PatternFly involves all sizes of code updates to these resources.

Every time code is merged a prerelease is published

Whenever code is merged into one of PatternFly’s GitHub repos, a prerelease is published to npm. These prerelease versions can be easily identified because they all have a ‘prerelease.x’ suffix trailing the version number (for example, “5.0.0-prerelease.22”). This labeling helps ensure that products are only ever intentionally pulling in an untested prerelease version, rather than inadvertently upgrading to a non-tested prerelease version.

Once the PatternFly team has wrapped up their final code freeze at the end of each quarter, their release architect identifies the release candidate versions and passes them off to be tested in products.

Currently, up to 4 Red Hat products are engaged in release candidate testing:

• OpenShift console
• Cost Management/Koku
• Keycloak
• ODH (sometimes)

During testing, each product goes through a similar process. Each product team:

1. Updates their PatternFly dependency to the release candidates
2. Opens a pull request to initiate continuous integration processes, so that their full testing framework can run with the release candidates
3. Manually checks for visual regressions or run time errors

If any of the testing products finds an unexpected visual change, observes any build or tests failures, or discovers any runtime errors, the PatternFly team responds by:

1. Investigating the issue
2. Either reverting the change in PatternFly that is causing the issue or releasing a fix to ensure the change is not breaking
3. Beginning the testing process again with the newer, updated release candidate to catch any remaining issues

Note: We welcome other products to join our testing process. Participating products benefit from always staying current with the latest promoted PatternFly releases. Additionally, the PatternFly team is always committed to withholding breaking changes from each latest release. Our only request is that products are willing to engage with the team during every release window to help identify issues or green-light the release candidate within a few days of its identification. If you want to be involved, reach out to us on Slack.

Every quarter, a new minor version of PatternFly is published

For example, if version 5.1.0 of PatternFly was released in the previous quarter, it is considered the ‘latest’ version of PatternFly. As soon as the latest version of PatternFly is released, work begins on the next minor release (starting with the prerelease process outlined previously).

Once 5.2.0-prerelease.X is feature complete, it is identified as the release candidate.

Once every product engaged in release candidate testing has affirmed that there are no more issues, regressions, or new bugs, the release candidate versions from prerelease drop the ‘-prerelease.X’ suffix and are promoted to ‘latest’ in npm.

The team continues to publish these minor version updates until the next major release of PatternFly.

PatternFly’s development is spread across four sprints each quarter, which include different stages of the development process

Once per year, PatternFly publishes a major release

PatternFly’s major releases (for example, PatternFly v4, v5, v6, etc.) are the only planned releases that include breaking changes. Currently, the team aims to release a major release annually at the end of the second quarter. With each major release, to assist with the adoption process, the PatternFly team is committed to providing the following:

• A GitHub view of the highest impact changes and highest priority features being delivered with the major release — available months before the major release is scheduled to be published
• A GitHub view of the comprehensive list of slated breaking changes being incorporated into the release — available months before the major release is scheduled to be published
• Multiple rounds of alpha testing of the major release candidate, done in partnership with multiple Red Hat products
• Codemods that simplify and streamline an automatic upgrade — provided alongside the major release
• A comprehensive upgrade guide containing instructions for upgrading to the major release version and a detailed list of release notes — published on the PatternFly site
• Release highlights outlining the most impactful changes included in the major release — published on the PatternFly site

Each major release will also include an update to the versioned prefix in all CSS classes and variable names (for example, changing “ — pf-v5-global — link — Color” to “ — pf-v6-global — link — Color”). This update will help prevent style collisions for products that have multiple major versions of PatternFly running simultaneously in their UI.

PatternFly’s release process will continue to evolve

The team’s release processes and schedule is ongoing and iterative. There has already been some big enhancements to the release flow, but they will continue to listen to feedback and adapt processes when it’s needed.

PatternFly’s release process is cyclical, which ensures that PatternFly is constantly being upgraded and improved

For example, in the future, we would like to automatically open pull requests in dependent product repos whenever there is a feature release version bump. This change would help the team identify any possible breaking changes early on and would jump start the latest release upgrade process sooner.

But, for now, PatternFly is able to deliver you the latest and greatest by following the process is as described in this article. We’re excited for what’s to come and hope that you are too!

Have a story of your own? Write with us! Our community thrives on diverse voices — let’s hear yours.