update doc and workflow args #863
Conversation
Signed-off-by: craig <cbrookes@redhat.com> rh-pre-commit.version: 2.2.0 rh-pre-commit.check-secrets: ENABLED
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #863 +/- ##
==========================================
- Coverage 80.20% 78.93% -1.28%
==========================================
Files 64 80 +16
Lines 4492 6209 +1717
==========================================
+ Hits 3603 4901 +1298
- Misses 600 971 +371
- Partials 289 337 +48
Flags with carried forward coverage won't be shown. Click here to find out more.
|
| description: Kuadrant Operator version | ||
| default: 0.0.0 | ||
| description: Kuadrant Operator version (excluding the v) | ||
| default: "200.20.2-replace" |
There was a problem hiding this comment.
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.
| ### 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
- always cut a new release from main of each dependency if it has changed
- pin the versions of the dependencies on main and move them as needed
There was a problem hiding this comment.
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.
No description provided.