From 33372740d13f847fb77dcb6f2b5ef2e6c895b4c8 Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Thu, 11 Jan 2024 14:20:45 +0100 Subject: [PATCH 01/17] [rfc] Initial commit with template and metadata --- rfcs/0000-kuadrant-release-process.md | 81 +++++++++++++++++++++++++++ 1 file changed, 81 insertions(+) create mode 100644 rfcs/0000-kuadrant-release-process.md diff --git a/rfcs/0000-kuadrant-release-process.md b/rfcs/0000-kuadrant-release-process.md new file mode 100644 index 00000000..03c4d2b4 --- /dev/null +++ b/rfcs/0000-kuadrant-release-process.md @@ -0,0 +1,81 @@ +# Kuadrant Release Process + +- Feature Name: `kuadrant-release-process` +- Start Date: 2024-01-11 +- RFC PR: [Kuadrant/architecture#0000](https://github.com/Kuadrant/architecture/pull/0000) +- Issue tracking: [Kuadrant/architecture#0000](https://github.com/Kuadrant/architecture/issues/0000) + +# Summary +[summary]: #summary + +One paragraph explanation of the feature. + +# Motivation +[motivation]: #motivation + +Why are we doing this? What use cases does it support? What is the expected outcome? + +# Guide-level explanation +[guide-level-explanation]: #guide-level-explanation + +Explain the proposal as if it was implemented and you were teaching it to Kuadrant user. That generally means: + +- Introducing new named concepts. +- Explaining the feature largely in terms of examples. +- Explaining how a user should *think* about the feature, and how it would impact the way they already use Kuadrant. It should explain the impact as concretely as possible. +- If applicable, provide sample error messages, deprecation warnings, or migration guidance. +- If applicable, describe the differences between teaching this to existing and new Kuadrant users. + +# Reference-level explanation +[reference-level-explanation]: #reference-level-explanation + +This is the technical portion of the RFC. Explain the design in sufficient detail that: + +- Its interaction with other features is clear. +- It is reasonably clear how the feature would be implemented. +- How error would be reported to the users. +- Corner cases are dissected by example. + +The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work. + +# Drawbacks +[drawbacks]: #drawbacks + +Why should we *not* do this? + +# Rationale and alternatives +[rationale-and-alternatives]: #rationale-and-alternatives + +- Why is this design the best in the space of possible designs? +- What other designs have been considered and what is the rationale for not choosing them? +- What is the impact of not doing this? + +# Prior art +[prior-art]: #prior-art + +Discuss prior art, both the good and the bad, in relation to this proposal. +A few examples of what this can include are: + +- Does another project have a similar feature? +- What can be learned from it? What's good? What's less optimal? +- Papers: Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background. + +This section is intended to encourage you as an author to think about the lessons from other tentatives - successful or not, provide readers of your RFC with a fuller picture. + +Note that while precedent set by other projects is some motivation, it does not on its own motivate an RFC. + +# Unresolved questions +[unresolved-questions]: #unresolved-questions + +- What parts of the design do you expect to resolve through the RFC process before this gets merged? +- What parts of the design do you expect to resolve through the implementation of this feature before stabilization? +- What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC? + +# Future possibilities +[future-possibilities]: #future-possibilities + +Think about what the natural extension and evolution of your proposal would be and how it would affect the platform and project as a whole. Try to use this section as a tool to further consider all possible interactions with the project and its components in your proposal. Also consider how this all fits into the roadmap for the project and of the relevant sub-team. + +This is also a good place to "dump ideas", if they are out of scope for the RFC you are writing but otherwise related. + +Note that having something written down in the future-possibilities section is not a reason to accept the current or a future RFC; such notes should be in the section on motivation or rationale in this or subsequent RFCs. The section merely provides additional information. \ No newline at end of file From e6504d3cc09d51d0c26b256f95cc5bebae457d5c Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Thu, 11 Jan 2024 15:34:41 +0100 Subject: [PATCH 02/17] [rfc] Summary and Motivation --- rfcs/0000-kuadrant-release-process.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/rfcs/0000-kuadrant-release-process.md b/rfcs/0000-kuadrant-release-process.md index 03c4d2b4..9d938bd3 100644 --- a/rfcs/0000-kuadrant-release-process.md +++ b/rfcs/0000-kuadrant-release-process.md @@ -8,12 +8,15 @@ # Summary [summary]: #summary -One paragraph explanation of the feature. +Kuadrant is a set of components that their artifacts are built and delivered independently. This RFC aims to define every +aspect of the event of releasing a new version of the whole, in terms of versioning, cadence, communication, channels, etc. # Motivation [motivation]: #motivation -Why are we doing this? What use cases does it support? What is the expected outcome? +At the time being, there's no clear process nor guidelines to follow when releasing a new version of Kuadrant, which +leads to confusion and lack of transparency. We are currently relying on internal communication and certain people +in charge of the release process, which is not ideal. # Guide-level explanation [guide-level-explanation]: #guide-level-explanation From cba268471307fd0c0bf8e42d7571463f7810ecd5 Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Thu, 11 Jan 2024 17:10:28 +0100 Subject: [PATCH 03/17] [rfc] Guide-level explanation: Summary, Components and versioning, cadence --- rfcs/0000-kuadrant-release-process.md | 44 +++++++++++++++++++++++---- 1 file changed, 38 insertions(+), 6 deletions(-) diff --git a/rfcs/0000-kuadrant-release-process.md b/rfcs/0000-kuadrant-release-process.md index 9d938bd3..a9df780a 100644 --- a/rfcs/0000-kuadrant-release-process.md +++ b/rfcs/0000-kuadrant-release-process.md @@ -21,13 +21,45 @@ in charge of the release process, which is not ideal. # Guide-level explanation [guide-level-explanation]: #guide-level-explanation -Explain the proposal as if it was implemented and you were teaching it to Kuadrant user. That generally means: +First, we need to define what releasing Kuadrant means, in a clear and transparent way that communicates to the community +what's happening and what to expect. This includes: + +- Components included in each release +- Versioning +- Cadence +- Repositories and Hubs +- Documentation +- Communication + +## Components and versioning + +The set of components that are part of the _Kuadrant suite_ are the following: + +- [Authorino](https://github.com/Kuadrant/authorino): Kubernetes-native authorization service for tailor-made Zero Trust API security. +- [Authorino Operator](https://github.com/Kuadrant/authorino-operator): A Kubernetes Operator to manage Authorino instances. +- [Limitador](https://github.com/Kuadrant/limitador): A generic rate-limiter written in Rust. +- [Limitador Operator](https://github.com/Kuadrant/limitador-operator/): A Kubernetes Operator to manage Limitador deployments. +- [Wasm Shim](https://github.com/Kuadrant/wasm-shim/): A Proxy-Wasm module written in Rust, acting as a shim between Envoy and Limitador. +- [Multicluster Gateway Controller](https://github.com/Kuadrant/multicluster-gateway-controller): Provides multi-cluster +connectivity and global load balancing. +- [Kuadrant Operator](https://github.com/Kuadrant/kuadrant-operator/): The Operator to install and manage the lifecycle +of the Kuadrant components deployments. + +Each of them needs to be versioned independently, and the versioning scheme should follow [Semantic Versioning](https://semver.org/). +The technical details of how to release each component are out of the scope of this RFC and could be found in the +[Kuadrant components CI/CD](https://github.com/Kuadrant/architecture/pull/41) RFC. + +By releasing a new version of Kuadrant, we mean releasing a new version of every component in the suite, with their +corresponding semantic versioning, and being the version of the **Kuadrant Operator** the one that defines the version of +the whole suite. + +## Cadence + +The frequency of the previously mentioned components, with the exception of the **Kuadrant Operator**, could vary +depending on the particular component needs. However, the **Kuadrant Operator** should be released every 2 weeks, +including the latest released version of every component in the suite. + -- Introducing new named concepts. -- Explaining the feature largely in terms of examples. -- Explaining how a user should *think* about the feature, and how it would impact the way they already use Kuadrant. It should explain the impact as concretely as possible. -- If applicable, provide sample error messages, deprecation warnings, or migration guidance. -- If applicable, describe the differences between teaching this to existing and new Kuadrant users. # Reference-level explanation [reference-level-explanation]: #reference-level-explanation From 34ec8f4f4e03070b0076247c6ab2a66afffd83f7 Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Fri, 12 Jan 2024 15:11:43 +0100 Subject: [PATCH 04/17] [rfc] Guilde-level explanation: Artifacts, repositories and hubs --- rfcs/0000-kuadrant-release-process.md | 32 ++++++++++++++++++++++++++- 1 file changed, 31 insertions(+), 1 deletion(-) diff --git a/rfcs/0000-kuadrant-release-process.md b/rfcs/0000-kuadrant-release-process.md index a9df780a..ff5707f5 100644 --- a/rfcs/0000-kuadrant-release-process.md +++ b/rfcs/0000-kuadrant-release-process.md @@ -59,7 +59,37 @@ The frequency of the previously mentioned components, with the exception of the depending on the particular component needs. However, the **Kuadrant Operator** should be released every 2 weeks, including the latest released version of every component in the suite. - +For a more in-depth analysis of the cadence of each component, please refer to the +[Kuadrant Release Cadence RFC](https://github.com/pmccarthy/architecture/blob/release-cadence-proposal/rfcs/0007-project-release-cadence.md). + +## Repositories and Hubs + +Every component in Kuadrant has its own repository, and the source code is hosted in GitHub, mentioned in the previous +section. However, the images built and manifests generated are hosted in different registries, depending on the +component. The following table shows the different registries used by each component: + +| Component | Artifacts | Registry / Hub | +|---------------------------------|------------------------------------------------|----------------------------------------------------------------------------------------| +| Authorino | authorino images | [Quay.io](https://quay.io/repository/kuadrant/authorino) | +| Authorino Operator | authorino-operator images | [Quay.io](https://quay.io/repository/kuadrant/authorino-operator) | +| | authorino-operator-bundle images | [Quay.io](https://quay.io/repository/kuadrant/authorino-operator-bundle) | +| | authorino-operator-catalog images | [Quay.io](https://quay.io/repository/kuadrant/authorino-operator-catalog) | +| | authorino-operator manifests | [OperatorHub.io](https://operatorhub.io/operator/authorino-operator) | +| Limitador | limitador server images | [Quay.io](https://quay.io/repository/kuadrant/limitador) | +| | limitador crate | [Crates.io](https://crates.io/crates/limitador) | +| Limitador Operator | limitador-operator images | [Quay.io](https://quay.io/repository/kuadrant/limitador-operator) | +| | limitador-operator-bundle images | [Quay.io](https://quay.io/repository/kuadrant/limitador-operator-bundle) | +| | limitador-operator-catalog images | [Quay.io](https://quay.io/repository/kuadrant/limitador-operator-catalog) | +| | limitador-operator manifests | [OperatorHub.io](https://operatorhub.io/operator/limitador-operator) | +| Wasm Shim | wasm-shim images | [Quay.io](https://quay.io/repository/kuadrant/wasm-shim) | +| Multicluster Gateway Controller | multicluster-gateway-controller images | [Quay.io](https://quay.io/repository/kuadrant/multicluster-gateway-controller) | +| | multicluster-gateway-controller-bundle images | [Quay.io](https://quay.io/repository/kuadrant/multicluster-gateway-controller-bundle) | +| | multicluster-gateway-controller-catalog images | [Quay.io](https://quay.io/repository/kuadrant/multicluster-gateway-controller-catalog) | +| Policy Controller | policy-controller images | [Quay.io](https://quay.io/repository/kuadrant/policy-controller) | +| Kuadrant Operator | kuadrant-operator images | [Quay.io](https://quay.io/repository/kuadrant/kuadrant-operator) | +| | kuadrant-operator-bundle images | [Quay.io](https://quay.io/repository/kuadrant/kuadrant-operator-bundle) | +| | kuadrant-operator-catalog images | [Quay.io](https://quay.io/repository/kuadrant/kuadrant-operator-catalog) | +| | kuadrant-operator manifests | [OperatorHub.io](https://operatorhub.io/operator/kuadrant-operator) | # Reference-level explanation [reference-level-explanation]: #reference-level-explanation From a7cd956adffe57305f5cd362bd08eb6d13ec23d1 Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Mon, 15 Jan 2024 16:21:46 +0100 Subject: [PATCH 05/17] [rfc] Guide-level explanation: Documentation and Communication --- rfcs/0000-kuadrant-release-process.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/rfcs/0000-kuadrant-release-process.md b/rfcs/0000-kuadrant-release-process.md index ff5707f5..d623f84a 100644 --- a/rfcs/0000-kuadrant-release-process.md +++ b/rfcs/0000-kuadrant-release-process.md @@ -91,6 +91,25 @@ component. The following table shows the different registries used by each compo | | kuadrant-operator-catalog images | [Quay.io](https://quay.io/repository/kuadrant/kuadrant-operator-catalog) | | | kuadrant-operator manifests | [OperatorHub.io](https://operatorhub.io/operator/kuadrant-operator) | +## Documentation + +The documentation for the Kuadrant suite is compiled and available on the [Kuadrant website](https://kuadrant.io/). One +can find the source of the documentation within each component repository, in the `docs` directory. It's important to +note that keeping the documentation up to date is a responsibility of the component maintainers, and it needs to be +done before releasing a new version of the component. The importance of keeping a clear and up-to-date documentation +is crucial for the success of the project. + +## Communication + +Another important aspect of releasing a new version of the Kuadrant suite is the communication with the community and +other teams within the organization. A few examples of the communication channels that need to be updated are: + +- Changelog generation +- Release notes +- Slack channel, in Red Hat and Kubernetes workspaces +- Blog post, if applicable +- Social media, if applicable + # Reference-level explanation [reference-level-explanation]: #reference-level-explanation From 88244329ae62ce6a6eb50b02f05b4aa7706065b8 Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Mon, 15 Jan 2024 17:10:13 +0100 Subject: [PATCH 06/17] [rfc] Reference-level explanation: Components, versioning and cadence --- rfcs/0000-kuadrant-release-process.md | 46 +++++++++++++++++++++++---- 1 file changed, 40 insertions(+), 6 deletions(-) diff --git a/rfcs/0000-kuadrant-release-process.md b/rfcs/0000-kuadrant-release-process.md index d623f84a..82ab5fed 100644 --- a/rfcs/0000-kuadrant-release-process.md +++ b/rfcs/0000-kuadrant-release-process.md @@ -113,14 +113,48 @@ other teams within the organization. A few examples of the communication channel # Reference-level explanation [reference-level-explanation]: #reference-level-explanation -This is the technical portion of the RFC. Explain the design in sufficient detail that: +As mentioned in the previous section, the Kuadrant suite is composed of several components, each of them with its own +set of artifacts and versioning scheme. Defining the release process of the whole suite is a complex task, and it's +not only about the technical details of releasing the components, but also about the communication and transparency +with the community. It also involves the definition of the cadence of the releases, and the frequency of the releases +of each component. This section aims to provide a more in-depth analysis of the different aspects of the release process. -- Its interaction with other features is clear. -- It is reasonably clear how the feature would be implemented. -- How error would be reported to the users. -- Corner cases are dissected by example. +## Components and versioning + +Taking into account the different components listed in the [Guide-level explanation section](#guide-level-explanation), +at the time of cutting a release for any of them, it's important to keep in mind what section of the version to bump, +given a version number MAJOR.MINOR.PATCH, increment the: + +* MAJOR version when you make incompatible API changes +* MINOR version when you add functionality in a backward compatible manner +* PATCH version when you make backward compatible bug fixes + +Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. + +A more detailed explanation of the versioning scheme can be found in the [Semantic Versioning](https://semver.org/) website. + +## Cadence -The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work. +Once the project is stable enough, and it's adoption increases, the community will be expecting a certain degree of +commitment from the maintainers, and that includes a regular release cadence. The frequency of the releases of the +different components could vary depending on the particular component needs. However, the **Kuadrant Operator** as mentioned +in the previous section, should be released every 2 weeks as it's been already proposed, including the latest released +version of every component in the suite. There are a few reasons for this: + +- Delivering Unparalleled Value to Customers: Regular releases can provide customers with regular updates and improvements. +These updates can include new features and essential bug fixes, thus enhancing the overall value delivered to the customers. +- Maximizing Deployment Efficiency: By releasing software at regular intervals, teams can align their activities with +available resources and environments, ensuring optimal utilization. This leads to increased efficiency in the deployment process. +- Risk Management: Regular releases can help identify and fix issues early, reducing the risk of major failures that could +affect customers. +- Feedback Cycle: Regular releases allow for quicker feedback cycles. This means that any issues or improvements +identified by users can be addressed promptly, leading to a more refined product over time. +- Synchronization: Regular releases can help synchronize work across different teams or departments, creating a more +reliable, dependable solution development and delivery process. +- Reduced Complexity: Managing a smaller number of releases can reduce complexity. For example, having many different +releases out in the field can lead to confusion and management overhead. + +By committing to a release cadence, software projects can benefit from improved efficiency, risk management, faster feedback cycles, synchronization, and reduced complexity. # Drawbacks [drawbacks]: #drawbacks From 3cb9203d8e1b5cd9f02d7e3859dd95aced26b01f Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Tue, 16 Jan 2024 10:27:20 +0100 Subject: [PATCH 07/17] [rfc] Unifying everything under Guide Level explanation --- rfcs/0000-kuadrant-release-process.md | 109 +++++++++++--------------- 1 file changed, 45 insertions(+), 64 deletions(-) diff --git a/rfcs/0000-kuadrant-release-process.md b/rfcs/0000-kuadrant-release-process.md index 82ab5fed..22911064 100644 --- a/rfcs/0000-kuadrant-release-process.md +++ b/rfcs/0000-kuadrant-release-process.md @@ -9,7 +9,8 @@ [summary]: #summary Kuadrant is a set of components that their artifacts are built and delivered independently. This RFC aims to define every -aspect of the event of releasing a new version of the whole, in terms of versioning, cadence, communication, channels, etc. +aspect of the event of releasing a new version of the whole, in terms of versioning, cadence, communication, channels, +handover to other teams, etc. # Motivation [motivation]: #motivation @@ -22,14 +23,11 @@ in charge of the release process, which is not ideal. [guide-level-explanation]: #guide-level-explanation First, we need to define what releasing Kuadrant means, in a clear and transparent way that communicates to the community -what's happening and what to expect. This includes: - -- Components included in each release -- Versioning -- Cadence -- Repositories and Hubs -- Documentation -- Communication +what's happening and what to expect. The Kuadrant suite is composed of several components, each of them with its own +set of artifacts and versioning scheme. Defining the release process of the whole suite is a complex task, and it's +not only about the technical details of releasing the components, but also about the communication and transparency +with the community, the definition of the frequency of the releases, and when it's ready to be handover to other teams like +QA. This section aims to provide guidelines for the different aspects of the release process. ## Components and versioning @@ -43,24 +41,53 @@ The set of components that are part of the _Kuadrant suite_ are the following: - [Multicluster Gateway Controller](https://github.com/Kuadrant/multicluster-gateway-controller): Provides multi-cluster connectivity and global load balancing. - [Kuadrant Operator](https://github.com/Kuadrant/kuadrant-operator/): The Operator to install and manage the lifecycle -of the Kuadrant components deployments. + of the Kuadrant components deployments. -Each of them needs to be versioned independently, and the versioning scheme should follow [Semantic Versioning](https://semver.org/). -The technical details of how to release each component are out of the scope of this RFC and could be found in the -[Kuadrant components CI/CD](https://github.com/Kuadrant/architecture/pull/41) RFC. +Each of them needs to be versioned independently, and the versioning scheme should follow [Semantic Versioning]. At +the time of cutting a release for any of them, it's important to keep in mind what section of the version to bump, +given a version number MAJOR.MINOR.PATCH, increment the: + +* MAJOR version when you make incompatible API changes +* MINOR version when you add functionality in a backward compatible manner +* PATCH version when you make backward compatible bug fixes + +Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. + +A more detailed explanation of the versioning scheme can be found in the [Semantic Versioning](https://semver.org/) website. By releasing a new version of Kuadrant, we mean releasing a new version of every component in the suite, with their corresponding semantic versioning, and being the version of the **Kuadrant Operator** the one that defines the version of the whole suite. +The technical details of how to release each component are out of the scope of this RFC and could be found in the +[Kuadrant components CI/CD](https://github.com/Kuadrant/architecture/pull/41) RFC. + ## Cadence -The frequency of the previously mentioned components, with the exception of the **Kuadrant Operator**, could vary -depending on the particular component needs. However, the **Kuadrant Operator** should be released every 2 weeks, -including the latest released version of every component in the suite. +Once the project is stable enough, and it's adoption increases, the community will be expecting a certain degree of +commitment from the maintainers, and that includes a regular release cadence. The frequency of the releases of the +different components could vary depending on the particular component needs. However, the **Kuadrant Operator** +it's been discussed in the past that it should be released every 2 weeks, including the latest released version +of every component in the suite. There's another RFC that focuses on the actual frequency of each component, one could +refer to the [Kuadrant Release Cadence RFC](https://github.com/pmccarthy/architecture/blob/release-cadence-proposal/rfcs/0007-project-release-cadence.md). + +There are a few reasons for this: + +- Delivering Unparalleled Value to Customers: Regular releases can provide customers with regular updates and improvements. + These updates can include new features and essential bug fixes, thus enhancing the overall value delivered to the customers. +- Maximizing Deployment Efficiency: By releasing software at regular intervals, teams can align their activities with + available resources and environments, ensuring optimal utilization. This leads to increased efficiency in the deployment process. +- Risk Management: Regular releases can help identify and fix issues early, reducing the risk of major failures that could + affect customers. +- Feedback Cycle: Regular releases allow for quicker feedback cycles. This means that any issues or improvements + identified by users can be addressed promptly, leading to a more refined product over time. +- Synchronization: Regular releases can help synchronize work across different teams or departments, creating a more + reliable, dependable solution development and delivery process. +- Reduced Complexity: Managing a smaller number of releases can reduce complexity. For example, having many different + releases out in the field can lead to confusion and management overhead. -For a more in-depth analysis of the cadence of each component, please refer to the -[Kuadrant Release Cadence RFC](https://github.com/pmccarthy/architecture/blob/release-cadence-proposal/rfcs/0007-project-release-cadence.md). +By committing to a release cadence, software projects can benefit from improved efficiency, risk management, faster feedback +cycles, synchronization, and reduced complexity. ## Repositories and Hubs @@ -110,52 +137,6 @@ other teams within the organization. A few examples of the communication channel - Blog post, if applicable - Social media, if applicable -# Reference-level explanation -[reference-level-explanation]: #reference-level-explanation - -As mentioned in the previous section, the Kuadrant suite is composed of several components, each of them with its own -set of artifacts and versioning scheme. Defining the release process of the whole suite is a complex task, and it's -not only about the technical details of releasing the components, but also about the communication and transparency -with the community. It also involves the definition of the cadence of the releases, and the frequency of the releases -of each component. This section aims to provide a more in-depth analysis of the different aspects of the release process. - -## Components and versioning - -Taking into account the different components listed in the [Guide-level explanation section](#guide-level-explanation), -at the time of cutting a release for any of them, it's important to keep in mind what section of the version to bump, -given a version number MAJOR.MINOR.PATCH, increment the: - -* MAJOR version when you make incompatible API changes -* MINOR version when you add functionality in a backward compatible manner -* PATCH version when you make backward compatible bug fixes - -Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. - -A more detailed explanation of the versioning scheme can be found in the [Semantic Versioning](https://semver.org/) website. - -## Cadence - -Once the project is stable enough, and it's adoption increases, the community will be expecting a certain degree of -commitment from the maintainers, and that includes a regular release cadence. The frequency of the releases of the -different components could vary depending on the particular component needs. However, the **Kuadrant Operator** as mentioned -in the previous section, should be released every 2 weeks as it's been already proposed, including the latest released -version of every component in the suite. There are a few reasons for this: - -- Delivering Unparalleled Value to Customers: Regular releases can provide customers with regular updates and improvements. -These updates can include new features and essential bug fixes, thus enhancing the overall value delivered to the customers. -- Maximizing Deployment Efficiency: By releasing software at regular intervals, teams can align their activities with -available resources and environments, ensuring optimal utilization. This leads to increased efficiency in the deployment process. -- Risk Management: Regular releases can help identify and fix issues early, reducing the risk of major failures that could -affect customers. -- Feedback Cycle: Regular releases allow for quicker feedback cycles. This means that any issues or improvements -identified by users can be addressed promptly, leading to a more refined product over time. -- Synchronization: Regular releases can help synchronize work across different teams or departments, creating a more -reliable, dependable solution development and delivery process. -- Reduced Complexity: Managing a smaller number of releases can reduce complexity. For example, having many different -releases out in the field can lead to confusion and management overhead. - -By committing to a release cadence, software projects can benefit from improved efficiency, risk management, faster feedback cycles, synchronization, and reduced complexity. - # Drawbacks [drawbacks]: #drawbacks From dc8018a61f7c81fb3c424fa757d77f90168ff709 Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Tue, 16 Jan 2024 11:14:45 +0100 Subject: [PATCH 08/17] [rfc] Guide Level explanation: Handover to QA --- rfcs/0000-kuadrant-release-process.md | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/rfcs/0000-kuadrant-release-process.md b/rfcs/0000-kuadrant-release-process.md index 22911064..e4d77195 100644 --- a/rfcs/0000-kuadrant-release-process.md +++ b/rfcs/0000-kuadrant-release-process.md @@ -62,6 +62,33 @@ the whole suite. The technical details of how to release each component are out of the scope of this RFC and could be found in the [Kuadrant components CI/CD](https://github.com/Kuadrant/architecture/pull/41) RFC. +## Handover to QA + +Probably the most important and currently missing step in the release process is the handover to the Quality Assurance +(QA) team. The QA team is responsible for testing the different components of the Kuadrant suite, and they need to +be aware of the new version of the suite that is going to be released, what are the changes that are included, bug fixes +and new features in order they can plan their testing processes accordingly. The handover to QA should happen once the +release candidate is ready, and it's been tested by the Engineering team. The QA team should be notified in advance +of the release, and they should be able to test the release candidate before the actual release happens. + +There is an ideal time to hand over to the QA team for testing, especially since we are using GitHub for orchestration, +we could briefly define it in the following steps: + +1. Complete Development Work: The engineering team completes their work included in the milestone and it's merged to main branch. +2. Prepare Release: The engineering team creates a release branch from the main branch, including the particular changes +that configure the release (manifests, version bump, etc.) +3. Tag Release: The engineering team tags the current state of the main branch as a release candidate. This creates a +snapshot of the codebase that can be tested without affecting the main branch and builds the deliverables. +4. Notify QA Team: At this time, the engineering team can notify the QA team that the deliverables for the release candidate +are ready for testing. This notification can be done through comments on GitHub issues or via other communication channels +like Slack. +5. Testing: The QA team tests the release candidate, checking for any bugs or issues. They can use GitHub's issue tracking +system to report any problems they find. +6. Iterate: Based on the feedback from the QA team, the development team makes any necessary adjustments and repeats the +process until the release candidate is deemed ready for production. +7. Publish Release: Once the release candidate is ready, the engineering team publishes the release. This means that the +Github release draft is published, and the artifacts are uploaded to the corresponding registries. + ## Cadence Once the project is stable enough, and it's adoption increases, the community will be expecting a certain degree of From bd3274a6e29e777b1a0441a9ea1413417b83d769 Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Tue, 16 Jan 2024 18:10:47 +0100 Subject: [PATCH 09/17] [rfc] Addressing comments after first review --- rfcs/0000-kuadrant-release-process.md | 36 +++++++++++++-------------- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/rfcs/0000-kuadrant-release-process.md b/rfcs/0000-kuadrant-release-process.md index e4d77195..3e2447d2 100644 --- a/rfcs/0000-kuadrant-release-process.md +++ b/rfcs/0000-kuadrant-release-process.md @@ -55,9 +55,9 @@ Additional labels for pre-release and build metadata are available as extensions A more detailed explanation of the versioning scheme can be found in the [Semantic Versioning](https://semver.org/) website. -By releasing a new version of Kuadrant, we mean releasing a new version of every component in the suite, with their -corresponding semantic versioning, and being the version of the **Kuadrant Operator** the one that defines the version of -the whole suite. +By releasing a new version of Kuadrant, we mean releasing the set of components with their corresponding semantic versioning, +some of them maybe freshly released, or others still using versioning from the previous one, and being the version of the +**Kuadrant Operator** the one that defines the version of the whole suite. The technical details of how to release each component are out of the scope of this RFC and could be found in the [Kuadrant components CI/CD](https://github.com/Kuadrant/architecture/pull/41) RFC. @@ -74,27 +74,26 @@ of the release, and they should be able to test the release candidate before the There is an ideal time to hand over to the QA team for testing, especially since we are using GitHub for orchestration, we could briefly define it in the following steps: -1. Complete Development Work: The engineering team completes their work included in the milestone and it's merged to main branch. -2. Prepare Release: The engineering team creates a release branch from the main branch, including the particular changes -that configure the release (manifests, version bump, etc.) -3. Tag Release: The engineering team tags the current state of the main branch as a release candidate. This creates a -snapshot of the codebase that can be tested without affecting the main branch and builds the deliverables. -4. Notify QA Team: At this time, the engineering team can notify the QA team that the deliverables for the release candidate -are ready for testing. This notification can be done through comments on GitHub issues or via other communication channels -like Slack. -5. Testing: The QA team tests the release candidate, checking for any bugs or issues. They can use GitHub's issue tracking -system to report any problems they find. -6. Iterate: Based on the feedback from the QA team, the development team makes any necessary adjustments and repeats the +1. Complete Development Work: The engineering team completes their work included in the milestone. +2. Create Release Candidate: The engineering team creates Release Candidate builds and manifests for all components required +for the release +3. Notify QA Team: At this time, the engineering team can notify the QA team that the deliverables for the release candidate +are ready for testing. This notification can be done through the GitHub Kuadrant board, or simply a public message in the +Kuadrant Slack channel. +4. Testing: The QA team tests the release candidate, checking for any bugs or issues. Then QA reports all the bugs as +GitHub issues and communicates testing status back publicly on Slack and/or email. +5. Iterate: Based on the feedback from the QA team, the development team makes any necessary adjustments and repeats the process until the release candidate is deemed ready for production. -7. Publish Release: Once the release candidate is ready, the engineering team publishes the release. This means that the -Github release draft is published, and the artifacts are uploaded to the corresponding registries. +6. Publish Release: Once QA communicates that the testing has been successfully finished, the engineering team will publish +the release both on Github and in the corresponding registries, updates documentation for the new release, and communicates +it to all channels specified in Communication section. ## Cadence Once the project is stable enough, and it's adoption increases, the community will be expecting a certain degree of commitment from the maintainers, and that includes a regular release cadence. The frequency of the releases of the different components could vary depending on the particular component needs. However, the **Kuadrant Operator** -it's been discussed in the past that it should be released every 2 weeks, including the latest released version +it's been discussed in the past that it should be released every 3-4 weeks initially, including the latest released version of every component in the suite. There's another RFC that focuses on the actual frequency of each component, one could refer to the [Kuadrant Release Cadence RFC](https://github.com/pmccarthy/architecture/blob/release-cadence-proposal/rfcs/0007-project-release-cadence.md). @@ -160,7 +159,8 @@ other teams within the organization. A few examples of the communication channel - Changelog generation - Release notes -- Slack channel, in Red Hat and Kubernetes workspaces +- Github Release publication +- Slack channel in Kubernetes workspace - Blog post, if applicable - Social media, if applicable From ea2d4af04972c6372d1d855220d7b3dd0521cc6b Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Wed, 17 Jan 2024 14:22:44 +0100 Subject: [PATCH 10/17] [rfc] Updating documentation section --- rfcs/0000-kuadrant-release-process.md | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/rfcs/0000-kuadrant-release-process.md b/rfcs/0000-kuadrant-release-process.md index 3e2447d2..b11e2471 100644 --- a/rfcs/0000-kuadrant-release-process.md +++ b/rfcs/0000-kuadrant-release-process.md @@ -146,11 +146,23 @@ component. The following table shows the different registries used by each compo ## Documentation +It's important to note that keeping the documentation up to date is a responsibility of the component maintainers, and +it needs to be done before releasing a new version of the component. The importance of keeping a clear and up-to-date +documentation is crucial for the success of the project. + The documentation for the Kuadrant suite is compiled and available on the [Kuadrant website](https://kuadrant.io/). One -can find the source of the documentation within each component repository, in the `docs` directory. It's important to -note that keeping the documentation up to date is a responsibility of the component maintainers, and it needs to be -done before releasing a new version of the component. The importance of keeping a clear and up-to-date documentation -is crucial for the success of the project. +can find the source of the documentation within each component repository, in the `docs` directory. However, making this +information available on the website is a manual process, and should be done by the maintainers of the project. The +process of updating the documentation is simple and consists of the following steps: + +1. Update the documentation in the corresponding component repository. +2. In [https://github.com/Kuadrant/docs.kuadrant.io/](https://github.com/Kuadrant/docs.kuadrant.io/), update the value of +the `import_url` within the `multirepo` in the `plugins` section of the [mkdocs.yml](https://github.com/Kuadrant/docs.kuadrant.io/blob/main/mkdocs.yml) +file, to point to the tag or branch of the component repository that contains the updated documentation. +3. Once the changes are merged to main, the workflow that updates the website will be triggered, and the documentation +will be updated. +4. If for some reason it's needed to trigger the workflow manually, one can do it from the GitHub Actions tab in the +[docs.kuadrant.io](https://github.com/Kuadrant/docs.kuadrant.io/actions/workflows/build.yaml) (`Actions > ci > Run Workflow`). ## Communication From 89c214501205c53d5457b183ba198b0bbfec2f59 Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Wed, 17 Jan 2024 14:54:07 +0100 Subject: [PATCH 11/17] [rfc] Rationale and alternatives, prior art, unresolved questions and future possibilities --- rfcs/0000-kuadrant-release-process.md | 34 ++++++++------------------- 1 file changed, 10 insertions(+), 24 deletions(-) diff --git a/rfcs/0000-kuadrant-release-process.md b/rfcs/0000-kuadrant-release-process.md index b11e2471..d0820dd1 100644 --- a/rfcs/0000-kuadrant-release-process.md +++ b/rfcs/0000-kuadrant-release-process.md @@ -176,44 +176,30 @@ other teams within the organization. A few examples of the communication channel - Blog post, if applicable - Social media, if applicable -# Drawbacks -[drawbacks]: #drawbacks - -Why should we *not* do this? # Rationale and alternatives [rationale-and-alternatives]: #rationale-and-alternatives -- Why is this design the best in the space of possible designs? -- What other designs have been considered and what is the rationale for not choosing them? -- What is the impact of not doing this? +The alternative to the proposal is to keep the current process, which is not ideal and leads to confusion and lack of +transparency. # Prior art [prior-art]: #prior-art -Discuss prior art, both the good and the bad, in relation to this proposal. -A few examples of what this can include are: - -- Does another project have a similar feature? -- What can be learned from it? What's good? What's less optimal? -- Papers: Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background. - -This section is intended to encourage you as an author to think about the lessons from other tentatives - successful or not, provide readers of your RFC with a fuller picture. +There's been an organically grown process for releasing new versions of the Kuadrant suite, which is not documented and +it's been changing over time. However, there are some documentation for some of the components, worth mentioning: -Note that while precedent set by other projects is some motivation, it does not on its own motivate an RFC. +* [Authorino release process](https://docs.google.com/document/d/1tLveyv8Zwe0wKyfUTWOlEnFeMB5aVGqIVDUjVYWax0U) +* [Limitador release process](https://github.com/Kuadrant/limitador/blob/main/RELEASE.md) # Unresolved questions [unresolved-questions]: #unresolved-questions -- What parts of the design do you expect to resolve through the RFC process before this gets merged? -- What parts of the design do you expect to resolve through the implementation of this feature before stabilization? -- What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC? +* What would be Kuadrant support policy? +* How many version are we going to back-port security and bug fixes to? +* What other teams need to be involved in the release process? # Future possibilities [future-possibilities]: #future-possibilities -Think about what the natural extension and evolution of your proposal would be and how it would affect the platform and project as a whole. Try to use this section as a tool to further consider all possible interactions with the project and its components in your proposal. Also consider how this all fits into the roadmap for the project and of the relevant sub-team. - -This is also a good place to "dump ideas", if they are out of scope for the RFC you are writing but otherwise related. - -Note that having something written down in the future-possibilities section is not a reason to accept the current or a future RFC; such notes should be in the section on motivation or rationale in this or subsequent RFCs. The section merely provides additional information. \ No newline at end of file +Once the release process is accepted and battle-tested, we could aim to automate the process as much as possible. \ No newline at end of file From 76d8d0ce2638f663c61ef5531c86d2f54f2c9851 Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Tue, 20 Feb 2024 10:13:48 +0100 Subject: [PATCH 12/17] [rfc] Redefined QA handover/green flagging * A brief process from QA to asserting a release candidate --- rfcs/0000-kuadrant-release-process.md | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/rfcs/0000-kuadrant-release-process.md b/rfcs/0000-kuadrant-release-process.md index d0820dd1..0205e0e9 100644 --- a/rfcs/0000-kuadrant-release-process.md +++ b/rfcs/0000-kuadrant-release-process.md @@ -8,7 +8,7 @@ # Summary [summary]: #summary -Kuadrant is a set of components that their artifacts are built and delivered independently. This RFC aims to define every +Kuadrant is a set of components whose artifacts are built and delivered independently. This RFC aims to define every aspect of the event of releasing a new version of the whole, in terms of versioning, cadence, communication, channels, handover to other teams, etc. @@ -62,14 +62,16 @@ some of them maybe freshly released, or others still using versioning from the p The technical details of how to release each component are out of the scope of this RFC and could be found in the [Kuadrant components CI/CD](https://github.com/Kuadrant/architecture/pull/41) RFC. -## Handover to QA +## QA Sanity Check -Probably the most important and currently missing step in the release process is the handover to the Quality Assurance +Probably the most important and currently missing step in the release process is the green flagging from the Quality Assurance (QA) team. The QA team is responsible for testing the different components of the Kuadrant suite, and they need to be aware of the new version of the suite that is going to be released, what are the changes that are included, bug fixes -and new features in order they can plan their testing processes accordingly. The handover to QA should happen once the -release candidate is ready, and it's been tested by the Engineering team. The QA team should be notified in advance -of the release, and they should be able to test the release candidate before the actual release happens. +and new features in order they can plan their testing processes accordingly. This check is not meant to be a fully fledged +assessment from the QA team as it would be with a downstream project when it's handover to them, it's aimed to not take +more than 1-2 days, and be expected to be fully automated in the future. This step will happen once the release candidate +is ready, and it's been tested by the Engineering team. The QA team should be notified in advance of the release, and +they should be able to assert the release candidate is ready before the actual release happens. There is an ideal time to hand over to the QA team for testing, especially since we are using GitHub for orchestration, we could briefly define it in the following steps: @@ -80,8 +82,8 @@ for the release 3. Notify QA Team: At this time, the engineering team can notify the QA team that the deliverables for the release candidate are ready for testing. This notification can be done through the GitHub Kuadrant board, or simply a public message in the Kuadrant Slack channel. -4. Testing: The QA team tests the release candidate, checking for any bugs or issues. Then QA reports all the bugs as -GitHub issues and communicates testing status back publicly on Slack and/or email. +4. Flagging/Testing: The QA team do the actual assertion/testing of the release candidate, checking for any obvious bugs or issues. +Then QA reports all the bugs as GitHub issues and communicates testing status back publicly on Slack and/or email. 5. Iterate: Based on the feedback from the QA team, the development team makes any necessary adjustments and repeats the process until the release candidate is deemed ready for production. 6. Publish Release: Once QA communicates that the testing has been successfully finished, the engineering team will publish From c4dcbd8b5c50b304fd97d73d2b153c982d3d6077 Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Tue, 20 Feb 2024 15:32:08 +0100 Subject: [PATCH 13/17] [rfc] Removing policy-controller, adding DNS Operator * TLS and DNS policies are managed by the Kuadrant Operator --- rfcs/0000-kuadrant-release-process.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/rfcs/0000-kuadrant-release-process.md b/rfcs/0000-kuadrant-release-process.md index 0205e0e9..83a80469 100644 --- a/rfcs/0000-kuadrant-release-process.md +++ b/rfcs/0000-kuadrant-release-process.md @@ -40,6 +40,8 @@ The set of components that are part of the _Kuadrant suite_ are the following: - [Wasm Shim](https://github.com/Kuadrant/wasm-shim/): A Proxy-Wasm module written in Rust, acting as a shim between Envoy and Limitador. - [Multicluster Gateway Controller](https://github.com/Kuadrant/multicluster-gateway-controller): Provides multi-cluster connectivity and global load balancing. +- [DNS Operator](https://github.com/Kuadrant/dns-operator): A Kubernetes Operator to manage DNS in single and multi-cluster +environments. - [Kuadrant Operator](https://github.com/Kuadrant/kuadrant-operator/): The Operator to install and manage the lifecycle of the Kuadrant components deployments. @@ -140,7 +142,9 @@ component. The following table shows the different registries used by each compo | Multicluster Gateway Controller | multicluster-gateway-controller images | [Quay.io](https://quay.io/repository/kuadrant/multicluster-gateway-controller) | | | multicluster-gateway-controller-bundle images | [Quay.io](https://quay.io/repository/kuadrant/multicluster-gateway-controller-bundle) | | | multicluster-gateway-controller-catalog images | [Quay.io](https://quay.io/repository/kuadrant/multicluster-gateway-controller-catalog) | -| Policy Controller | policy-controller images | [Quay.io](https://quay.io/repository/kuadrant/policy-controller) | +| DNS Operator | dns-operator images | [Quay.io](https://quay.io/repository/kuadrant/dns-operator) | +| | dns-operator-bundle images | [Quay.io](https://quay.io/repository/kuadrant/dns-operator-bundle) | +| | dns-operator-catalog images | [Quay.io](https://quay.io/repository/kuadrant/dns-operator-catalog) | | Kuadrant Operator | kuadrant-operator images | [Quay.io](https://quay.io/repository/kuadrant/kuadrant-operator) | | | kuadrant-operator-bundle images | [Quay.io](https://quay.io/repository/kuadrant/kuadrant-operator-bundle) | | | kuadrant-operator-catalog images | [Quay.io](https://quay.io/repository/kuadrant/kuadrant-operator-catalog) | From 96d77cb7747c11fe27ddc692fd6f664c649cebe8 Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Tue, 20 Feb 2024 16:54:25 +0100 Subject: [PATCH 14/17] [fix] Typos and links --- rfcs/0000-kuadrant-release-process.md | 38 +++++++++++++-------------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/rfcs/0000-kuadrant-release-process.md b/rfcs/0000-kuadrant-release-process.md index 83a80469..c1af6e57 100644 --- a/rfcs/0000-kuadrant-release-process.md +++ b/rfcs/0000-kuadrant-release-process.md @@ -45,8 +45,8 @@ environments. - [Kuadrant Operator](https://github.com/Kuadrant/kuadrant-operator/): The Operator to install and manage the lifecycle of the Kuadrant components deployments. -Each of them needs to be versioned independently, and the versioning scheme should follow [Semantic Versioning]. At -the time of cutting a release for any of them, it's important to keep in mind what section of the version to bump, +Each of them needs to be versioned independently, and the versioning scheme should follow [Semantic Versioning](https://semver.org/). +At the time of cutting a release for any of them, it's important to keep in mind what section of the version to bump, given a version number MAJOR.MINOR.PATCH, increment the: * MAJOR version when you make incompatible API changes @@ -70,10 +70,12 @@ Probably the most important and currently missing step in the release process is (QA) team. The QA team is responsible for testing the different components of the Kuadrant suite, and they need to be aware of the new version of the suite that is going to be released, what are the changes that are included, bug fixes and new features in order they can plan their testing processes accordingly. This check is not meant to be a fully fledged -assessment from the QA team as it would be with a downstream project when it's handover to them, it's aimed to not take -more than 1-2 days, and be expected to be fully automated in the future. This step will happen once the release candidate -is ready, and it's been tested by the Engineering team. The QA team should be notified in advance of the release, and -they should be able to assert the release candidate is ready before the actual release happens. +assessment from the QA team when it's handover to them, it's aimed to not take more than 1-2 days, and ideally expected +to be fully automated. This step will happen once the release candidate has no PRs pending to be merged, and it has been +tested by the Engineering team. The QA team should work closely to the engineering throughout the process, both teams aiming +for zero handover time and continuous delivery mindset, so immediate testing can be triggered on release candidates once +handed over. This process should happen without the need of formal communication between the teams or any overhead in +general, but by keeping constant synergy between quality and product engineering instead. There is an ideal time to hand over to the QA team for testing, especially since we are using GitHub for orchestration, we could briefly define it in the following steps: @@ -81,20 +83,17 @@ we could briefly define it in the following steps: 1. Complete Development Work: The engineering team completes their work included in the milestone. 2. Create Release Candidate: The engineering team creates Release Candidate builds and manifests for all components required for the release -3. Notify QA Team: At this time, the engineering team can notify the QA team that the deliverables for the release candidate -are ready for testing. This notification can be done through the GitHub Kuadrant board, or simply a public message in the -Kuadrant Slack channel. -4. Flagging/Testing: The QA team do the actual assertion/testing of the release candidate, checking for any obvious bugs or issues. +3. Flagging/Testing: The QA team do the actual assertion/testing of the release candidate, checking for any obvious bugs or issues. Then QA reports all the bugs as GitHub issues and communicates testing status back publicly on Slack and/or email. -5. Iterate: Based on the feedback from the QA team, the development team makes any necessary adjustments and repeats the +4. Iterate: Based on the feedback from the QA team, the Engineering team makes any necessary adjustments and repeats the process until the release candidate is deemed ready for production. -6. Publish Release: Once QA communicates that the testing has been successfully finished, the engineering team will publish +5. Publish Release: Once QA communicates that the testing has been successfully finished, the engineering team will publish the release both on Github and in the corresponding registries, updates documentation for the new release, and communicates it to all channels specified in Communication section. ## Cadence -Once the project is stable enough, and it's adoption increases, the community will be expecting a certain degree of +Once the project is stable enough, and its adoption increases, the community will be expecting a certain degree of commitment from the maintainers, and that includes a regular release cadence. The frequency of the releases of the different components could vary depending on the particular component needs. However, the **Kuadrant Operator** it's been discussed in the past that it should be released every 3-4 weeks initially, including the latest released version @@ -103,12 +102,12 @@ refer to the [Kuadrant Release Cadence RFC](https://github.com/pmccarthy/archite There are a few reasons for this: -- Delivering Unparalleled Value to Customers: Regular releases can provide customers with regular updates and improvements. - These updates can include new features and essential bug fixes, thus enhancing the overall value delivered to the customers. +- Delivering Unparalleled Value to Users: Regular releases can provide users with regular updates and improvements. + These updates can include new features and essential bug fixes, thus enhancing the overall value delivered to the users. - Maximizing Deployment Efficiency: By releasing software at regular intervals, teams can align their activities with available resources and environments, ensuring optimal utilization. This leads to increased efficiency in the deployment process. - Risk Management: Regular releases can help identify and fix issues early, reducing the risk of major failures that could - affect customers. + affect users. - Feedback Cycle: Regular releases allow for quicker feedback cycles. This means that any issues or improvements identified by users can be addressed promptly, leading to a more refined product over time. - Synchronization: Regular releases can help synchronize work across different teams or departments, creating a more @@ -162,8 +161,8 @@ information available on the website is a manual process, and should be done by process of updating the documentation is simple and consists of the following steps: 1. Update the documentation in the corresponding component repository. -2. In [https://github.com/Kuadrant/docs.kuadrant.io/](https://github.com/Kuadrant/docs.kuadrant.io/), update the value of -the `import_url` within the `multirepo` in the `plugins` section of the [mkdocs.yml](https://github.com/Kuadrant/docs.kuadrant.io/blob/main/mkdocs.yml) +2. Follow the instruction in [https://github.com/Kuadrant/docs.kuadrant.io/](https://github.com/Kuadrant/docs.kuadrant.io/) +to update the Docs pointers to the tag or branch of the component repository that contains the updated documentation. file, to point to the tag or branch of the component repository that contains the updated documentation. 3. Once the changes are merged to main, the workflow that updates the website will be triggered, and the documentation will be updated. @@ -195,7 +194,8 @@ transparency. There's been an organically grown process for releasing new versions of the Kuadrant suite, which is not documented and it's been changing over time. However, there are some documentation for some of the components, worth mentioning: -* [Authorino release process](https://docs.google.com/document/d/1tLveyv8Zwe0wKyfUTWOlEnFeMB5aVGqIVDUjVYWax0U) +* [Authorino release process](https://github.com/Kuadrant/authorino/blob/main/RELEASE.md) +* [Authorino Operator release process](https://github.com/Kuadrant/authorino-operator/blob/main/RELEASE.md) * [Limitador release process](https://github.com/Kuadrant/limitador/blob/main/RELEASE.md) # Unresolved questions From c8e299e55551b1f79e8e465c75dae205c82e3598 Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Wed, 21 Feb 2024 10:03:28 +0100 Subject: [PATCH 15/17] [rfc] Clarifying point on resource optimization --- rfcs/0000-kuadrant-release-process.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/rfcs/0000-kuadrant-release-process.md b/rfcs/0000-kuadrant-release-process.md index c1af6e57..a4b293cc 100644 --- a/rfcs/0000-kuadrant-release-process.md +++ b/rfcs/0000-kuadrant-release-process.md @@ -104,8 +104,9 @@ There are a few reasons for this: - Delivering Unparalleled Value to Users: Regular releases can provide users with regular updates and improvements. These updates can include new features and essential bug fixes, thus enhancing the overall value delivered to the users. -- Maximizing Deployment Efficiency: By releasing software at regular intervals, teams can align their activities with - available resources and environments, ensuring optimal utilization. This leads to increased efficiency in the deployment process. +- Resource Optimization: By releasing software at regular intervals, teams can align their activities with + available resources and environments, ensuring optimal utilization. This leads to increased efficiency in the deployment + process and reduces the risk of resource wastage. - Risk Management: Regular releases can help identify and fix issues early, reducing the risk of major failures that could affect users. - Feedback Cycle: Regular releases allow for quicker feedback cycles. This means that any issues or improvements @@ -163,7 +164,6 @@ process of updating the documentation is simple and consists of the following st 1. Update the documentation in the corresponding component repository. 2. Follow the instruction in [https://github.com/Kuadrant/docs.kuadrant.io/](https://github.com/Kuadrant/docs.kuadrant.io/) to update the Docs pointers to the tag or branch of the component repository that contains the updated documentation. -file, to point to the tag or branch of the component repository that contains the updated documentation. 3. Once the changes are merged to main, the workflow that updates the website will be triggered, and the documentation will be updated. 4. If for some reason it's needed to trigger the workflow manually, one can do it from the GitHub Actions tab in the From 11677fa744decc3f6fa033c366275c5d3be5e193 Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Wed, 21 Feb 2024 10:52:49 +0100 Subject: [PATCH 16/17] [rfc] Pseudo formula stating the independent versioning of dependencies * Kuadrant Suite version will have the Kuadrant Operator version * The rest of the dependencies are versioned independently --- rfcs/0000-kuadrant-release-process.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/rfcs/0000-kuadrant-release-process.md b/rfcs/0000-kuadrant-release-process.md index a4b293cc..06ecbb5f 100644 --- a/rfcs/0000-kuadrant-release-process.md +++ b/rfcs/0000-kuadrant-release-process.md @@ -61,6 +61,10 @@ By releasing a new version of Kuadrant, we mean releasing the set of components some of them maybe freshly released, or others still using versioning from the previous one, and being the version of the **Kuadrant Operator** the one that defines the version of the whole suite. +``` +Kuadrant Suite vx.y.z = Kuadrant Operator vx.y.z + Authorino Operator va.b.c + Limitador Operator vd.e.f + DNS Operator vg.h.i + MGC Controller vj.k.l + Wasm Shim vm.n.o +``` + The technical details of how to release each component are out of the scope of this RFC and could be found in the [Kuadrant components CI/CD](https://github.com/Kuadrant/architecture/pull/41) RFC. From a66f5624b40b428126783ef690779506ed83496d Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Wed, 21 Feb 2024 11:08:34 +0100 Subject: [PATCH 17/17] [rfc] Updating metadata --- ...nt-release-process.md => 0008-kuadrant-release-process.md} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename rfcs/{0000-kuadrant-release-process.md => 0008-kuadrant-release-process.md} (98%) diff --git a/rfcs/0000-kuadrant-release-process.md b/rfcs/0008-kuadrant-release-process.md similarity index 98% rename from rfcs/0000-kuadrant-release-process.md rename to rfcs/0008-kuadrant-release-process.md index 06ecbb5f..2da224d6 100644 --- a/rfcs/0000-kuadrant-release-process.md +++ b/rfcs/0008-kuadrant-release-process.md @@ -2,8 +2,8 @@ - Feature Name: `kuadrant-release-process` - Start Date: 2024-01-11 -- RFC PR: [Kuadrant/architecture#0000](https://github.com/Kuadrant/architecture/pull/0000) -- Issue tracking: [Kuadrant/architecture#0000](https://github.com/Kuadrant/architecture/issues/0000) +- RFC PR: [Kuadrant/architecture#46](https://github.com/Kuadrant/architecture/pull/46) +- Issue tracking: [Kuadrant/architecture#59](https://github.com/Kuadrant/architecture/issues/59) # Summary [summary]: #summary