-
Story
-
Resolution: Done
-
Undefined
-
None
-
None
-
None
-
3
-
False
-
None
-
False
-
AppSvc Sprint 244, AppSvc Sprint 2246, AppSvc Sprint 2247, AppSvc Sprint 2248
Owner: Architect:
TBD
Story (Required)
As an SBO Developer I would like to release SBO 1.4.0
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.4.0 Is Available in OperatorHub: <PUT LINK HERE>
- (Upatream) SBO 1.4.0 Is Available in ArtifactHub: <PUT LINK HERE>
- (Downstream) SBO 1.4.0 is available in redhat-operators catalog source in OpenShift 4.10, 4.11 and 4.12
- Release notes updated
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: <New Feature/Enhancement/Known Issue/Bug
fix/Breaking change/Deprecated Functionality/Technology Preview>
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
- 1.5 (Upstream/Downstream) File a PR to bump the version (1.4.0): https://github.com/redhat-developer/service-binding-operator/pull/1476
- 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/releases/tag/v1.4.0
- 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/3486
- 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: <PUT LINK HERE>
- 4.4.2 Assign focals to Advisory
- 4.5 Update SBO version for CPaaS: <PUT LINK HERE>
- 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
- clones
-
APPSVC-1219 [Template] Release SBO vX.Y.Z - Clone this
- Backlog
- depends on
-
APPSVC-1402 Create SBO v1.4.0 Helm Chart
- New