Epic Goal

Simplify the upstream and downstream build process so that we can support z-stream releases for v1.0.

Why is this important?

• All Red Hat products must support security patching during the Full and Maintenance portions of their support lifecycle.
• Bug fixes that have significant customer impact may also warrant delivery via a z-stream fix.

Scenarios

1. Bug fix delivered upstream in next release (v0.13.0), but it impacts user experience in the prior release (v0.12.0)
2. Dependency update merged upstream in "main" branch which contains security-related fixes that need to be delivered in prior release stream.

Acceptance Criteria (Mandatory)

• Upstream agrees/documents process for creating z-stream branches in repos
• Backport pull requests can opened in upstream repositories, verified with CI and merged in "release branches".
• Downstream product can update sources with commits from upstream release branch (ex via CPaaS mid-stream).
• Downstream can release a "z-stream" of a product.
• Release Technical Enablement - Provide necessary release enablement details and documents.

Dependencies (internal and external)

1. Process for releasing a z-stream in CPaaS
2. Upstream process for creating z-stream releases.

Previous Work (Optional):

1. CPaaS automation for updating upstream sources.

Out of Scope

• Automate base image updates downstream
• z-stream for shipwright-io/triggers (this should be removed from the v1.0 product definition!)

Open questions:

1. Do we need to draft a SHIP (upstream enhancement proposal) for this?

Done Checklist

• Acceptance criteria are met
• Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
• User Journey automation is delivered
• Support and SRE teams are provided with enough skills to support the feature in production environment