Owner: Architect:

pmacik@redhat.com

Story (Required)

As an SBO Developer I would like to release SBO 1.3.3

Background (Required)

TBD

Out of scope

Helm Chart

In Scope

Upstream release
Downstream release

Approach(Required)

Productization process in details

Demo requirements(Required)

No Demo

Acceptance Criteria

Development:

• (Upstream) SBO 1.3.3 Is Available in OperatorHub: https://operatorhub.io/operator/service-binding-operator/stable/service-binding-operator.v1.3.3
• (Upatream) SBO 1.3.3 Is Available in ArtifactHub: https://artifacthub.io/packages/olm/community-operators/service-binding-operator/1.3.3
• (Downstream) SBO X.Y.Z is available in redhat-operators catalog source in OpenShift 4.9, 4.10, 4.11 (required) and 4.12
• Release notes updated: https://github.com/openshift/openshift-docs/pull/55095

QE:

• Acceptance tests with x86_64 architecture PASSED
• Acceptance tests with ppc64le (IBM Power) architecture PASSED
• Acceptance tests with s390x (IBM Z) architecture PASSED
• Acceptance tests with aarch64 (ARM64) architecture PASSED
• Performance evaluation PASSED

Documentation: Yes (needs-docs|upstream-docs)

• Upstream: Review Required

• Downstream: Yes

Release Notes Type: Bug fix

Release Checklist

Items to tick off depending on the type of Release:

• For an Upstream Release , You need to tick off all the items in Steps 1, 2 and 3.
• For a Downstream Release , You need to tick off all the items in Steps 1, 2 , 3, 4.

Steps

• 1.Preparation steps
  • 1.1 Release engineer takes ownership of a release Jira story
  • 1.2 (Upstream) Assign owner to create SBO Helm Chart task
  • 1.3 Compose Release Notes (Refer to Composing Release Notes)
  • 1.4 (Downstream) Inform Content Writer of the Pull Request with Release notes: https://github.com/openshift/openshift-docs/pull/55095
  • 1.5 (Upstream/Downstream) File a PR to bump the version (1.3.3): https://github.com/redhat-developer/service-binding-operator/pull/1360
  • 1.6 (Upstream/Downstream) Create a Release branch
  • 1.7 (Downstream) Inform Release Management team (Contact/Release Management) of pending release and agree on exact release date.
• 2. Github Release
  • 2.1 Validate planned PRs in Github milestones are closed.
  • 2.2 Tag commit for the release: https://github.com/redhat-developer/service-binding-operator/tree/v1.3.3
  • 2.3 Document release notes
  • 2.4 Create a non-OLM release of SBO (install via release.yaml)
  • 2.5 Close the github milestone
• 3. Upstream Release
  • 3.1 Checkout the release commit (tagged)
  • 3.2 Prepare PR to publish to OperatorHub: https://github.com/k8s-operatorhub/community-operators/pull/2157
  • 3.3 Ensure SBO Helm chart has been created and released on ArtifactHub
• 4. Downstream Release
  • 4.1 Validate planned Jira Stories for the release are closed
  • 4.2 Inform Third party integration teams of our intent to publish a new release.
  • 4.3 Update Release Notes Text in Jira Story for downstream release. (Refer to Composing Release Notes section)
  • 4.4 Create an errata based on a previous releases’ errata
    • 4.4.1 Clone an Advisory: https://errata.devel.redhat.com/advisory/108115
    • 4.4.2 Assign focals to Advisory
  • 4.5 Update SBO version for CPaaS: https://gitlab.cee.redhat.com/ocpappsvc/service-binding-operator/-/merge_requests/18
  • 4.6 Create build images for SBO midstream repo
  • 4.7 Attach builds (Operator and Bundle builds) to the errata
  • 4.8 Request Security approval if errata is of type RHSA (Red Hat Security Advisory)
  • 4.9 Request Doc/Content Writer approval
  • 4.10 Followup with QE owner to initiate QE Checklist
  • 4.11 Update product lifecycle support page and lifecycle policy page
  • 4.12 Close Jira releases
  • 4.13 Engage with DevSandbox focal to initiate deployment to Staging and Production

Legend

Unknown

Completed

Unsatisfied