Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

update doc and workflow args #863

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

update doc and workflow args #863

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 12 additions & 12 deletions .github/workflows/release.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,28 +7,28 @@ on:
description: Commit SHA, tag or branch name
required: true
kuadrantOperatorVersion:
description: Kuadrant Operator version
default: 0.0.0
description: Kuadrant Operator version (excluding the v)
default: "200.20.2-replace"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is "200.20.2-replace"? I'm guess it's meant to work a better example of a semantic version than "0.0.0" perhaps.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes exactly

type: string
authorinoOperatorVersion:
description: Authorino Operator bundle version
default: latest
description: Authorino Operator bundle version (excluding the v)
default: "200.20.2"
type: string
limitadorOperatorVersion:
description: Limitador Operator bundle version
default: latest
description: Limitador Operator bundle version (excluding the v)
default: "200.20.2"
type: string
dnsOperatorVersion:
description: DNS Operator bundle version
default: latest
description: DNS Operator bundle version (excluding the v)
default: "200.20.2"
type: string
wasmShimVersion:
description: WASM Shim version
default: latest
description: WASM Shim version (excluding the v)
default: "200.20.2"
type: string
replacesVersion:
description: Kuadrant Operator replaced version
default: 0.0.0-alpha
description: Kuadrant Operator replaced version (excluding the v)
default: "200.19.0"
type: string
prerelease:
description: Is the release a pre-release?
Expand Down
6 changes: 6 additions & 0 deletions RELEASE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,12 @@

## Process


### Regular Minor Release
Before releasing a new minor version of the Kuadrant Operator each dependency (see below) should also have a minor release if it has changes since the last release.

For each component, compare the git commit on the latest release against main if it has changed, beyond just version bumps, follow the release process for that dependency (linked below) before doing a release of Kuadrant-Operator. You will need to gather the new released versions as you go to use with the release of the kuadrant-operator.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this topic was discussed at the last Kuadrant community call. Maybe I misunderstood the conclusion (if there was any), but I left with the impression that cutting a release of a component wouldn't necessarily have to be such an automatic process as described here. Rather, some communication might be desirable.

This is first so people focused on the components can have a heads-up in case of an otherwise automatic cut of a new version of a component could "break a promise" of shipping specific issues within the next planned version of the component. If some of those issues risk overflowing to the version after that, at least communicating that to users beforehand (via reassigning milestones, labels, etc) would be nice.

The other reason raised was that such coupling between Kuadrant Operator and its dependencies regarding releases may not be desirable in the first place, on any condition. In general, each component has its own story and should be treated just like any other dependency (e.g., a Golang lib the Kuadrant Operator imports.) The exception to this rule being the obvious case where coupling exists anyway, such as for releasing a feature of Kuadrant Operator with direct counterparts in the components.

I'm guessing the pain point we're trying to fix with this proposed change to the release process in part derives from the often truncated communication that has to happen between Kuadrant and its components before cutting a release. To help mitigate that, it was proposed having a (rotating) "release coordinator". This person would not only help us with the communication, but by spotting opportunities to improve the release process overall. (cc @pmccarthy)

Speaking about improving the process, I think we should work on making the process of cutting a release of the components more efficient. I believe Authorino Operator can be a reference here. With a "click of a button", one can cut a new release of Authorino Operator today.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One of the main issues I see is that we run all of our tests against the latest main of each dependency, then at release time we sometimes step back in time to an actual release of a component. So I see two options to bring us to a saner place

  1. always cut a new release from main of each dependency if it has changed
  2. pin the versions of the dependencies on main and move them as needed

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If your going to cut a new release of each dependency it should be based of the sha's from the last nightly where all tests passed and not the current main's. Those changes many only be there minutes and brake the nightly builds. This main even mean that it is not the current main for kuadrant that is used in the release.

Pinning the versions of the dependencies in main is the better option. Nightly builds can patch the version to get the latest if that is needed. Subcomponents then can have their release cadence and kuadrant does not need to support the latest version of the subcomponents.


To release a version _“v0.W.Z”_ of Kuadrant Operator in GitHub and Quay.io, follow these steps:

1. Kuadrant dependencies need to be released first:
Expand Down
Loading